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Preface 


The Internet is global in scope, but this global internetwork is an open insecure medium. 
The Internet has revolutionised the computing and communications world for the purpose 
of development and support of client and server services. The availability of the Internet, 
along with powerful affordable computing and communications, has made possible a new 
paradigm of commercial world. This has been tremendously accelerated by the adoption 
of browsers and World Wide Web technology, allowing users easy access to information 
linked throughout the globe. The Internet has truly proven to be an essential vehicle of 
information trade today. 

The Internet is today a widespread information infrastructure, a mechanism for infor- 
mation dissemination, and a medium for collaboration and interaction between individuals, 
government agencies, financial institutions, academic circles and businesses of all sizes, 
without regard for geographic location. 

People have become increasingly dependent on the Internet for personal and profes- 
sional use regardless of whether it is for e-mail, file transfer, remote login, Web page 
access or commercial transactions. With the increased awareness and popularity of the 
Internet, Internet security problems have been brought to the fore. Internet security is 
not only extremely important, but more technically complex than in the past. The mere 
fact that business is being performed online over an insecure medium is enough to entice 
criminal activity to the Internet. 

The Internet access often creates a threat as a security flaw. To protect users from Internet- 
based attacks and to provide adequate solutions when security is imposed, cryptographic 
techniques must be employed to solve these problems. This book is designed to reflect the 
central role of cryptographic operations, principles, algorithms and protocols in Internet 
security. The remedy for all kinds of threats created by criminal activities should rely on 
cryptographic resolution. Authentication, message integrity and encryption are very impor- 
tant in cultivating, improving, and promoting Internet security. Without such authentication 
procedures, an attacker could impersonate anyone and then gain access to the network. 
Message integrity is required because data may be altered as it travels through the Internet. 
Without confidentiality by encryption, information may become truly public. 

The material in this book presents the theory and practice on Internet security and its 
implementation through a rigorous, thorough and qualitative presentation in depth. The 
level of the book is designed to be suitable for senior and graduate students, professional 
engineers and researchers as an introduction to Internet security principles. The book 
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consists of 11 chapters and focuses on the critical security issues related to the Internet. 
The following is a summary of the contents of each chapter. 

Chapter 1 begins with a brief history of the Internet and describes topics covering 
(1) networking fundamentals such as LANs (Ethernet, Token Ring, FDDI), WANs (Frame 
Relay, X.25, PPP) and ATM; (2) connecting devices such as circuit- and packet-switches, 
repeaters, bridges, routers, and gateways; (3) the OSI model which specifies the function- 
ality of its seven layers; and finally (4) a TCP/IP five-layer suite providing a hierarchical 
protocol made up of physical standards, a network interface and internetworking. 

Chapter 2 presents a state-of-the-art survey of the TCP/IP suite. Topics covered include 
(1) TCP/IP network layer protocols such as ICMP, IP version 4 and IP version 6 relat- 
ing to the IP packet format, addressing (including ARP, RARP and CIDR) and rout- 
ing; (2) transport layer protocols such as TCP and UDP; (3) HTTP for the World Wide 
Web; (4) FTP, TFTP and NFS protocols for file transfer; (5) SMTP, POP3, IMAP and 
MIME for e-mail; and (6) SNMP protocol for network management. 

Chapter 3 deals with some of the important contemporary block cipher algorithms that 
have been developed over recent years with an emphasis on the most widely used encryp- 
tion techniques such as Data Encryption Standard (DES), International Data Encryption 
Algorithm (IDEA), the RCS and RC6 encryption algorithms, and Advanced Encryption 
Standard (AES). AES specifies an FIPS-approved Rijndael algorithm (2001) that can pro- 
cess data blocks of 128 bits, using cipher keys with lengths of 128, 192 and 256 bits. 
DES is not new, but it has survived remarkably well over 20 years of intense cryptanal- 
ysis. The complete analysis of triple DES-EDE in CBC mode is also included., Pretty 
Good Privacy (PGP) used for electronic mail (e-mail) and file storage applications utilises 
IDEA for conventional block encryption, along with RSA for public key encryption and 
MDS for hash coding. RC5 and RC6 are both parameterised block algorithms of variable 
size, variable number of rounds, and a variable-length key. They are designed for great 
flexibility in both performance and level of security. 

Chapter 4 covers the various authentication techniques based on digital signatures. It 
is often necessary for communication parties to verify each other’s identity. One practical 
way to do this is the use of cryptographic authentication protocols employing a one-way 
hash function. Several contemporary hash functions (such as DMDC, MDS and SHA-1) 
are introduced to compute message digests or hash codes for providing a systematic 
approach to authentication. This chapter also extends the discussion to include the Internet 
standard HMAC, which is a secure digest of protected data. HMAC is used with a variety 
of different hash algorithms, including MDS and SHA-1. Transport Layer Security (TLS) 
also makes use of the HMAC algorithm. 

Chapter 5 describes several public-key cryptosystems brought in after conventional 
encryption. This chapter concentrates on their use in providing techniques for public-key 
encryption, digital signature and authentication. This chapter covers in detail the widely 
used Diffie-Hellman key exchange technique (1976), the Rivest-Schamir—Adleman 
(RSA) algorithm (1978), the ElGamal algorithm (1985), the Schnorr algorithm (1990), 
the Digital Signature Algorithm (DSA, 1991) and the Elliptic Curve Cryptosystem 
(ECC, 1985) and Elliptic Curve Digital Signature Algorithm (ECDSA, 1999). 

Chapter 6 presents profiles related to a public-key infrastructure (PKI) for the Internet. 
The PKI automatically manages public keys through the use of public-key certificates. The 
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Policy Approval Authority (PAA) is the root of the certificate management infrastructure. 
This authority is known to all entities at entire levels in the PKI, and creates guidelines that 
all users, CAs and subordinate policy-making authorities must follow. Policy Certificate 
Authorities (PCAs) are formed by all entities at the second level of the infrastructure. 
PCAs must publish their security policies, procedures, legal issues, fees and any other 
subjects they may consider necessary. Certification Authorities (CAs) form the next level 
below the PCAs. The PKI contains many CAs that have no policy-making responsibilities. 
A CA has any combination of users and RAs whom it certifies. The primary function of the 
CA is to generate and manage the public-key certificates that bind the user’s identity with 
the user’s public key. The Registration Authority (RA) is the interface between a user and 
a CA. The primary function of the RA is user identification and authentication on behalf 
of a CA. It also delivers the CA-generated certificate to the end user. X.500 specifies the 
directory service. X.509 describes the authentication service using the X.500 directory. 
X.509 certificates have evolved through three versions: version | in 1988, version 2 in 
1993 and version 3 in 1996. X.509 v3 is now found in numerous products and Internet 
standards. These three versions are explained in turn. Finally, Certificate Revocation 
Lists (CRLs) are used to list unexpired certificates that have been revoked. CRLs may 
be revoked for a variety of reasons, ranging from routine administrative revocations to 
situations where private keys are compromised. This chapter also includes the certification 
path validation procedure for the Internet PKI and architectural structures for the PKI 
certificate management infrastructure. 

Chapter 7 describes the IPsec protocol for network layer security. IPsec provides the 
capability to secure communications across a LAN, across a virtual private network (VPN) 
over the Internet or over a public WAN. Provision of IPsec enables a business to rely heav- 
ily on the Internet. The IPsec protocol is a set of security extensions developed by IETF to 
provide privacy and authentication services at the IP layer using cryptographic algorithms 
and protocols. To protect the contents of an IP datagram, there are two main transfor- 
mation types: the Authentication Header (AH) and the Encapsulating Security Payload 
(ESP). These are protocols to provide connectionless integrity, data origin authentication, 
confidentiality and an anti-replay service. A Security Association (SA) is fundamental 
to IPsec. Both AH and ESP make use of a SA that is a simple connection between a 
sender and receiver, providing security services to the traffic carried on it. This chapter 
also includes the OAKLEY key determination protocol and ISAKMP. 

Chapter 8 discusses Secure Socket Layer version 3 (SSLv3) and Transport Layer 
Security version 1 (TLSv1). The TLSv1 protocol itself is based on the SSLv3 protocol 
specification. Many of the algorithm-dependent data structures and rules are very simi- 
lar, so the differences between TLSv1 and SSLv3 are not dramatic. The TLSv1 protocol 
provides communications privacy and data integrity between two communicating parties 
over the Internet. Both protocols allow client/server applications to communicate in a 
way that is designed to prevent eavesdropping, tampering or message forgery. The SSL 
or TLS protocols are composed of two layers: Record Protocol and Handshake Protocol. 
The Record Protocol takes an upper-layer application message to be transmitted, frag- 
ments the data into manageable blocks, optionally compresses the data, applies a MAC, 
encrypts it, adds a header and transmits the result to TCP. Received data is decrypted to 
higher-level clients. The Handshake Protocol operated on top of the Record Layer is the 
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most important part of SSL or TLS. The Handshake Protocol consists of a series of mes- 
sages exchanged by client and server. This protocol provides three services between the 
server and client. The Handshake Protocol allows the client/server to agree on a protocol 
version, to authenticate each other by forming a MAC, and to negotiate an encryption 
algorithm and cryptographic keys for protecting data sent in an SSL record before the 
application protocol transmits or receives its first byte of data. 

A keyed hashing message authentication code (HMAC) is a secure digest of some 
protected data. Forging an HMAC is impossible without knowledge of the MAC secret. 
HMAC can be used with a variety of different hash algorithms: MD5 and SHA-1, denoting 
these as HMAC-MD5 (secret, data) and SHA-1 (secret, data). There are two differences 
between the SSLv3 scheme and the TLS MAC scheme: TSL makes use of the HMAC 
algorithm defined in RFC 2104; and TLS master-secret computation is also different from 
that of SSLv3. 

Chapter 9 describes e-mail security. Pretty Good Privacy (PGP), invented by Philip 
Zimmermann, is widely used in both individual and commercial versions that run on a 
variety of platforms throughout the global computer community. PGP uses a combination 
of symmetric secret-key and asymmetric public-key encryption to provide security services 
for e-mail and data files. PGP also provides data integrity services for messages and 
data files using digital signatures, encryption, compression (ZIP) and radix-64 conversion 
(ASCII Armor). With growing reliance on e-mail and file storage, authentication and 
confidentiality services are increasingly important. Multipurpose Internet Mail Extension 
(MIME) is an extension to the RFC 822 framework which defines a format for text 
messages sent using e-mail. MIME is actually intended to address some of the problems 
and limitations of the use of SMTP. S/MIME is a security enhancement to the MIME 
Internet e-mail format standard, based on technology from RSA Data Security. Although 
both PGP and S/MIME are on an JETF standards track, it appears likely that PGP will 
remain the choice for personal e-mail security for many users, while S/MIME will emerge 
as the industry standard for commercial and organisational use. The two PGP and S/MIME 
schemes are covered in this chapter. 

Chapter 10 discusses the topic of firewalls as an effective means of protecting an 
internal system from Internet-based security threats. A firewall is a security gateway that 
controls access between the public Internet and a private internal network (or intranet). A 
firewall is an agent that screens network traffic in some way, blocking traffic it believes to 
be inappropriate, dangerous or both. The security concerns that inevitably arise between 
the sometimes hostile Internet and secure intranets are often dealt with by inserting one or 
more firewalls on the path between the Internet and the internal network. In reality, Internet 
access provides benefits to individual users, government agencies and most organisations. 
But this access often creates a security threat. 

Firewalls act as an intermediate server in handling SMTP and HTTP connections in 
either direction. Firewalls also require the use of an access negotiation and encapsulation 
protocol such as SOCKS to gain access to the Internet, to the intranet or both. Many 
firewalls support tri-homing, allowing the use of a DMZ network. To design and configure 
a firewall, it needs to be familiar with some basic terminology such as a bastion host, 
proxy server, SOCKS, choke point, DMZ, logging and alarming, VPN, etc. Firewalls are 
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classified into three main categories: packet filters, circuit-level gateways and application- 
level gateways. In this chapter, each of these firewalls is examined in turn. Finally, this 
chapter discusses screened host firewalls and how to implement a firewall strategy. To 
provide a certain level of security, the three basic firewall designs are considered: a 
single-homed bastion host, a dual-homed bastion host and a screened subnet firewall. 

Chapter 11 covers the SET protocol designed for protecting credit card transactions 
over the Internet. The recent explosion in e-commerce has created huge opportunities 
for consumers, retailers and financial institutions alike. SET relies on cryptography and 
X.509 v3 digital certificates to ensure message confidentiality, payment integrity and 
identity authentication. Using SET, consumers and merchants are protected by ensuring 
that payment information is safe and can only be accessed by the intended recipient. SET 
combats the risk of transaction information being altered in transit by keeping information 
securely encrypted at all times and by using digital certificates to verify the identity of 
those accessing payment details. SET is the only Internet transaction protocol to provide 
security through authentication. Message data is encrypted with a random symmetric 
key which is then encrypted using the recipient’s public key. The encrypted message, 
along with this digital envelope, is sent to the recipient. The recipient decrypts the digital 
envelope with a private key and then uses the symmetric key to recover the original 
message. SET addresses the anonymity of Internet shopping by using digital signatures and 
digital certificates to authenticate the banking relationships of cardholders and merchants. 
How to ensure secure payment card transactions on the Internet is fully explored in 
this chapter. 

The scope of this book is adequate to span a one- or two-semester course at a senior 
or first-year graduate level. As a reference book, it will be useful to computer engineers, 
communications engineers and system engineers. It is also suitable for self-study. The 
book is intended for use in both academic and professional circles, and it is also suitable 
for corporate training programmes or seminars for industrial organisations as well as 
research institutes. At the end of the book, there is a list of frequently used acronyms, 
and a bibliography. 


Man Young Rhee 
Seoul, Korea 
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Internetworking and Layered Models 


The Internet today is a widespread information infrastructure, but it is inherently an 
insecure channel for sending messages. When a message (or packet) is sent from one 
Website to another, the data contained in the message are routed through a number of 
intermediate sites before reaching its destination. The Internet was designed to accom- 
modate heterogeneous platforms so that people who are using different computers and 
operating systems can communicate. The history of the Internet is complex and involves 
many aspects — technological, organisational and community. The Internet concept has 
been a big step along the path towards electronic commerce, information acquisition and 
community operations. 

Early ARPANET researchers accomplished the initial demonstrations of packet- 
switching technology. In the late 1970s, the growth of the Internet was recognised and 
subsequently a growth in the size of the interested research community was accompanied 
by an increased need for a coordination mechanism. The Defense Advanced Research 
Projects Agency (DARPA) then formed an International Cooperation Board (ICB) to 
coordinate activities with some European countries centered on packet satellite research, 
while the Internet Configuration Control Board (ICCB) assisted DARPA in managing 
Internet activity. In 1983, DARPA recognised that the continuing growth of the Internet 
community demanded a restructuring of coordination mechanisms. The ICCB was dis- 
banded and in its place the Internet Activities Board (IAB) was formed from the chairs 
of the Task Forces. The IAB revitalised the Internet Engineering Task Force (IETF) as 
a member of the IAB. By 1985, there was a tremendous growth in the more practical 
engineering side of the Internet. This growth resulted in the creation of a substructure 
to the IETF in the form of working groups. DARPA was no longer the major player in 
the funding of the Internet. Since then, there has been a significant decrease in Internet 
activity at DARPA. The IAB recognised the increasing importance of IETF, and restruc- 
tured to recognise the Internet Engineering Steering Group (IESG) as the major standards 
review body. The IAB also restructured to create the Internet Research Task Force (IRTF) 
along with the IETF. 
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Since the early 1980s, the Internet has grown beyond its primarily research roots, to 
include both a broad user community and increased commercial activity. This growth 
in the commercial sector brought increasing concern regarding the standards process. 
Increased attention was paid to making progress, eventually leading to the formation of 
the Internet Society in 1991. In 1992, the Internet Activities Board was reorganised and 
renamed the Internet Architecture board (IAB) operating under the auspices of the Internet 
Society. The mutually supportive relationship between the new IAB, IESG and IETF led 
to them taking more responsibility for the approval of standards, along with the provision 
of services and other measures which would facilitate the work of the IETF. 


1.1. Networking Technology 


Data signals are transmitted from one device to another using one or more types of 
transmission media, including twisted-pair cable, coaxial cable and fibre-optic cable. A 
message to be transmitted is the basic unit of network communications. A message may 
consist of one or more cells, frames or packets which are the elemental units for network 
communications. Networking technology includes everything from local area networks 
(LANs) in a limited geographic area such as a single building, department or campus to 
wide area networks (WANs) over large geographical areas that may comprise a country, 
a continent or even the whole world. 


1.1.1. Local Area Networks (LANs) 


A local area network (LAN) is a communication system that allows a number of indepen- 
dent devices to communicate directly with each other in a limited geographic area such 
as a single office building, a warehouse or a campus. LANs are standardised by three 
architectural structures: Ethernet, token ring and fibre distributed data interface (FDDI). 


7.1.1.1. Ethernet 


Ethernet is a LAN standard originally developed by Xerox and later extended by a joint 
venture between Digital Equipment Corporation (DEC), Intel Corporation and Xerox. 
The access mechanism used in an Ethernet is called Carrier Sense Multiple Access with 
Collision Detection (CSMA/CD). In CSMA/CD, before a station transmits data, it must 
check the medium where any other station is currently using the medium. If no other 
station is transmitting, the station can send its data. If two or more stations send data 
at the same time, it may result in a collision. Therefore, all stations should continuously 
check the medium to detect any collision. If a collision occurs, all stations ignore the data 
received. The sending stations wait for a period of time before resending the data. To 
reduce the possibility of a second collision, the sending stations individually generate a 
random number that determinates how long the station should wait before resending data. 


7.1.1.2 Token Ring 


Token ring, a LAN standard originally developed by IBM, uses a logical ring topology. 
The access method used by CSMA/CD may result in collisions. Therefore, stations may 
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attempt to send data many times before a transmission captures a perfect link. This 
redundancy can create delays of indeterminable length if traffic is heavy. There is no way 
to predict either the occurrence of collisions or the delays produced by multiple stations 
attempting to capture the link at the same time. Token ring resolves this uncertainty by 
making stations take turns in sending data. 

As an access method, the token is passed from station to station in sequence until it 
encounters a station with data to send. The station to be sent data waits for the token. The 
station then captures the token and sends its data frame. This data frame proceeds around 
the ring and each station regenerates the frame. Each intermediate station examines the 
destination address, finds that the frame is addressed to another station, and relays it to 
its neighbouring station. The intended recipient recognises its own address, copies the 
message, checks for errors and changes four bits in the last byte of the frame to indicate 
that the address has been recognised and the frame copied. The full packet then continues 
around the ring until it returns to the station that sent it. 


7.1.1.3 Fiber Distributed Data Interface (FDDI) 


FDDI is a LAN protocol standardised by ANSI and ITU-T. It supports data rates of 
100 Mbps and provides a high-speed alternative to Ethernet and token ring. When FDDI 
was designed, the data rate of 100 Mbps required fibre-optic cable. 

The access method in FDDI is also called token passing. In a token ring network, 
a station can send only one frame each time it captures the token. In FDDI, the token 
passing mechanism is slightly different in that access is limited by time. Each station 
keeps a timer which shows when the token should leave the station. If a station receives 
the token earlier than the designated time, it can keep the token and send data until the 
scheduled leaving time. On the other hand, if a station receives the token at the designated 
time or later than this time, it should let the token pass to the next station and wait for 
its next turn. 

FDDI is implemented as a dual ring. In most cases, data transmission is confined to the 
primary ring. The secondary ring is provided in case of the primary ring’s failure. When 
a problem occurs on the primary ring, the secondary ring can be activated to complete 
data circuits and maintain service. 


1.1.2 Wide Area Networks (WANs) 


A WAN provides long-distance transmission of data, voice, image and video information 
over large geographical areas that may comprise a country, a continent or even the world. 
In contrast to LANs (which depend on their own hardware for transmission), WANs can 
utilise public, leased or private communication devices, usually in combination. 


7.1.2.1. PPP 


The Point-to-Point Protocol (PPP) is designed to handle the transfer of data using either 
asynchronous modem links or high-speed synchronous leased lines. The PPP frame uses 
the following format: 
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e Flag field: Each frame starts with a one-byte flag whose value is 7E(O111 1110). The 
flag is used for synchronisation at the bit level between the sender and receiver. 

e Address field: This field has the value of FF(1111 1111). 

e Control field: This field has the value of 03(0000 0011). 

e Protocol field: This is a two-byte field whose value is 0021(0000 0000 0010 0001) 
for TCP/IP. 

e Data field: The data field ranges up to 1500 bytes. 

e CRC: This is a two-byte cyclic redundancy check. Cyclic redundancy check (CRC) 
is implemented in the physical layer for use in the data link layer. A sequence of 
redundant bits (CRC) is appended to the end of a data unit so that the resulting data 
unit becomes exactly divisible by a predetermined binary number. At its destination, 
the incoming data unit is divided by the same number. If there is no remainder, the 
data unit is accepted. If a remainder exists, the data unit has been damaged in transit 
and therefore must be rejected. 


7.1.2.2 X.25 


X.25 is widely used, as the packet switching protocol provided for use in a WAN. It was 
developed by the ITU-T in 1976. X.25 is an interface between data terminal equipment 
and data circuit terminating equipment for terminal operations at the packet mode on a 
public data network. 

X.25 defines how a packet mode terminal can be connected to a packet network for 
the exchange of data. It describes the procedures necessary for establishing connection, 
data exchange, acknowledgement, flow control and data control. 


7.1.2.3 Frame Relay 


Frame relay is a WAN protocol designed in response to X.25 deficiencies. X.25 provides 
extensive error-checking and flow control. Packets are checked for accuracy at each station 
to which they are routed. Each station keeps a copy of the original frame until it receives 
confirmation from the next station that the frame has arrived intact. Such station-to-station 
checking is implemented at the data link layer of the OSI model, but X.25 only checks 
for errors from source to receiver at the network layer. The source keeps a copy of the 
original packet until it receives confirmation from the final destination. Much of the traffic 
on an X.25 network is devoted to error-checking to ensure reliability of service. Frame 
relay does not provide error-checking or require acknowledgement in the data link layer. 
Instead, all error-checking is left to the protocols at the network and transport layers, 
which use the frame relay service. Frame relay only operates at the physical and data 
link layer. 


1.1.2.4 Asynchronous Transfer Mode (ATM) 


ATM is a revolutionary idea for restructuring the infrastructure of data communication. It 
is designed to support the transmission of data, voice and video through a high data-rate 
transmission medium such as fibre-optic cable. ATM is a protocol for transferring cells. A 
cell is a small data unit of 53 bytes long, made of a 5-byte header and a 48-byte payload. 
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The header contains a virtual path identifier (VPI) and a virtual channel identifier (VCI). 
These two identifiers are used to route the cell through the network to the final destination. 

An ATM network is a connection-oriented cell switching network. This means that the 
unit of data is not a packet as in a packet switching network, or a frame as in a frame relay, 
but a cell. However, ATM, like X.25 and frame relay, is a connection-oriented network, 
which means that before two systems can communicate, they must make a connection. To 
start up a connection, a system uses a 20-byte address. After the connection is established, 
the combination of VPI/VCI leads a cell from its source to its final destination. 


1.2 Connecting Devices 


Connecting devices are used to connect the segments of a network together or to connect 
networks to create an internetwork. These devices are classified into five categories: 
switches, repeaters, bridges, routers and gateways. Each of these devices except the first 
one (switches) interacts with protocols at different layers of the OSI model. 

Repeaters forward all electrical signals and are active only at the physical layer. Bridges 
store and forward complete packets and affect the flow control of a single LAN. Bridges 
are active at the physical and data link layers. Routers provide links between two separate 
LANs and are active in the physical, data link and network layers. Finally, gateways 
provide translation services between incompatible LANs or applications, and are active 
in all layers. 

Connection devices that interact with protocols at different layers of the OSI model 
are shown in Figure 1.1. 


1.2.1 Switches 


A switched network consists of a series of interlinked switches. Switches are hard- 
ware/software devices capable of creating temporary connections between two or more 
devices to the switch but not to each other. Switching mechanisms are generally classified 
into three methods: circuit switching, packet switching and message switching. 
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Figure 1.1 Connecting devices. 


6 INTERNET SECURITY 


e Circuit switching creates a direct physical connection between two devices such as 
telephones or computers. Once a connection is made between two systems, circuit 
switching creates a dedicated path between two end users. The end users can use the 
path for as long as they want. 

e Packet switching is one way to provide a reasonable solution for data transmission. 
In a packet-switched network, data are transmitted in discrete units of variable-length 
blocks called packets. Each packet contains not only data, but also a header with 
control information. The packets are sent over the network node to node. At each 
node, the packet is stored briefly before being routed according to the information in 
its header. 

In the datagram approach to packet switching, each packet is treated independently 
of all others as though it exists alone. In the virtual circuit approach to packet switch- 
ing, if a single route is chosen between sender and receiver at the beginning of the 
session, all packets travel one after another along that route. Although these two 
approaches seem the same, there exists a fundamental difference between them. In 
circuit switching, the path between the two end users consists of only one channel. 
In the virtual circuit, the line is not dedicated to two users. The line is divided into 
channels and each channel can use one of the channels in a link. 

e Message switching is known as the store and forwarding method. In this approach, a 
computer (or a node) receives a message, stores it until the appropriate route is free, 
then sends it out. This method has now been phased out. 


1.2.2 Repeaters 


A repeater is an electronic device that operates on the physical layer only of the OSI 
model. A repeater boosts the transmission signal from one segment and continues the 
signal to another segment. Thus, a repeater allows us to extend the physical length of 
a network. Signals that carry information can travel a limited distance within a network 
before degradation of the data integrity due to noise. A repeater receives the signal before 
attenuation, regenerates the original bit pattern and puts the restored copy back on to 
the link. 


1.2.3. Bridges 


Bridges operate in both the physical and the data link layers of the OSI model. A sin- 
gle bridge connects different types of networks together and promotes interconnectivity 
between networks. Bridges divide a large network into smaller segments. Unlike repeaters, 
bridges contain logic that allows them to keep separate the traffic for each segment. 
Bridges are smart enough to relay a frame towards the intended recipient so that traffic can 
be filtered. In fact, this filtering operation makes bridges useful for controlling congestion, 
isolating problem links and promoting security through this partitioning of traffic. 

A bridge can access the physical addresses of all stations connected to it. When a 
frame enters a bridge, the bridge not only regenerates the signal but also checks the 
address of the destination and forwards the new copy to the segment to which the address 
belongs. When a bridge encounters a packet, it reads the address contained in the frame 
and compares that address with a table of all the stations on both segments. When it finds 
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a match, it discovers to which segment the station belongs and relays the packet to that 
segment only. 


1.2.4 Routers 


Routers operate in the physical, data link and network layers of the OSI model. The 
Internet is a combination of networks connected by routers. When a datagram goes from 
a source to a destination, it will probably pass through many routers until it reaches the 
router attached to the destination network. Routers determine the path a packet should 
take. Routers relay packets among multiple interconnected networks. In particular, an IP 
router forwards IP datagrams among the networks to which it connects. A router uses the 
destination address on a datagram to choose a next-hop to which it forwards the datagram. 
A packet sent from a station on one network to a station on a neighbouring network goes 
first to a jointly held router, which switches it over the destination network. In fact, the 
easiest way to build the Internet is to connect two or more networks with a router. Routers 
provide connections to many different types of physical networks: Ethernet, token ring, 
point-to-point links, FDDI and so on. 


e The routing module receives an IP packet from the processing module. If the packet 
is to be forwarded, it should be passed to the routing module. It finds the IP address 
of the next station along with the interface number from which the packet should 
be sent. It then sends the packet with information to the fragmentation module. The 
fragmentation module consults the MTU table to find the maximum transfer unit 
(MTU) for the specific interface number. 

e The routing table is used by the routing module to determine the next-hop address of 
the packet. Every router keeps a routing table that has one entry for each destination 
network. The entry consists of the destination network IP address, the shortest distance 
to reach the destination in hop count, and the next router (next hop) to which the 
packet should be delivered to reach its final destination. The hop count is the number 
of networks a packet enters to reach its final destination. A router should have a 
routing table to consult when a packet is ready to be forwarded. The routing table 
should specify the optimum path for the packet. The table can be either static or 
dynamic. A static table is one that is not changed frequently, but a dynamic table is 
one that is updated automatically when there is a change somewhere in the Internet. 
Today, the Internet needs dynamic routing tables. 

e A metric is a cost assigned for passing through a network. The total metric of a 
particular router is equal to the sum of the metrics of networks that comprise the 
route. A router chooses the route with the shortest (smallest value) metric. The metric 
assigned to each network depends on the type of protocol. The Routing Information 
Protocol (RIP) treats each network as one hop count. So if a packet passes through 10 
networks to reach the destination, the total cost is 10 hop counts. The Open Shortest 
Path First protocol (OSPF) allows the administrator to assign a cost for passing through 
a network based on the type of service required. A route through a network can have 
different metrics (costs). OSPF allows each router to have several routing tables based 
on the required type of service. The Border Gateway Protocol (BGP) defines the metric 


8 INTERNET SECURITY 


totally differently. The policy criterion in BGP is set by the administrator. The policy 
defines the paths that should be chosen. 


1.2.5 Gateways 


Gateways operate over the entire range in all seven layers of the OSI model. Internet 
routing devices have traditionally been called gateways. A gateway is a protocol converter 
which connects two or more heterogeneous systems and translates among them. The 
gateway thus refers to a device that performs protocol translation between devices. A 
gateway can accept a packet formatted for one protocol and convert it to a packet formatted 
for another protocol before forwarding it. The gateway understands the protocol used by 
each network linked into the router and is therefore able to translate from one to another. 


1.3 The OSI Model 


The Ethernet, originally called the Alto Aloha network, was designed by the Xerox Palo 
Alto Research Center in 1973 to provide communication for research and development 
CP/M computers. When in 1976 Xerox started to develop the Ethernet as a 20 Mbps 
product, the network prototype was called the Xerox Wire. In 1980, when the Digital, 
Intel and Xerox standard was published to make it a LAN standard at 10 Mbps, Xerox 
Wire changed its name back to Ethernet. Ethernet became a commercial product in 1980 
at 10 Mbps. The IEEE called its Ethernet 802.3 standard CSMA/CD (or carrier sense 
multiple access with collision detection). As the 802.3 standard evolved, it has acquired 
such names as Thicknet (IEEE 10Base-5), Thinnet or Cheapernet (10Base-2), Twisted 
Ethernet (10Base-T) and Fast Ethernet (100Base-T). 

The design of Ethernet preceded the development of the seven-layer OSI model. The 
Open System Interconnect (OSI) model was developed and published in 1982 by the 
International Organisation for Standardisation (ISO) as a generic model for data com- 
munication. The OSI model is useful because it is a broadly based document, widely 
available and often referenced. Since modularity of communication functions is a key 
design criterion in the OSI model, vendors who adhere to the standards and guidelines of 
this model can supply Ethernet-compatible devices, alternative Ethernet channels, higher- 
performance Ethernet networks and bridging protocols that easily and reliably connect 
other types of data network to Ethernet. 

Since the OSI model was developed after Ethernet and Signaling System #7 (SS7), 
there are obviously some discrepancies between these three protocols. Yet the functions 
and processes outlined in the OSI model were already in practice when Ethernet or SS7 
was developed. In fact, SS7 networks use point-to-point configurations between signalling 
points. Due to the point-to-point configurations and the nature of the transmissions, the 
simple data link layer does not require much complexity. 

The OSI reference model specifies the seven layers of functionality, as shown in 
Figure 1.2. It defines the seven layers from the physical layer (which includes the network 
adapters), up to the application layer, where application programs can access network ser- 
vices. However, the OSI model does not define the protocols that implement the functions 
at each layer. The OSI model is still important for compatibility, protocol independence 
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Layer OSI 
No. Layer 

vi Application 
6 Presentation 
5 Session 

4 Transport 
3 Network 

2 Data Link 
1 Physical 


Functionality 


* Provides user interface 

¢ System computing and user application process 

¢ Of the many application services, this layer provides support for 
services such as e-mail, remote file access and transfer, message 
handling services (X.400) to send an e-mail message, directory 
services (X.500) for distributed database sources and access for 
global information about various objects and services 


¢ Data interpretation (compression, encryption, formatting and 
syntax selection) and code transformations 


¢ Administrative control of transmissions and transfers between 
nodes 

* Dialogue control between two systems 

¢ Synchronisation process by inserting checkpoints into data 
stream 


¢ Source-to-destination delivery of entire message 

* Message segmentation at the sending layer and reassembling at 
the receiving layer 

¢ Transfer control by either connectionless or connection-oriented 
mechanism for delivering packets 

¢ Flow control for end-to-end services 

¢ Error control based on performing end-to-end rather than a single 
link 

¢ Source-to-destination delivery of individual packets 

* Routing or switching packets to final destination 


¢ Logical addressing to help distinguish the source/destination 
systems 


¢ Framing, physical addressing, data flow control, access control 
and error control 


¢ Physical control of the actual data circuit (electrical, mechanical 
and optical) 





Figure 1.2 ISO/OSI model. 


and the future growth of network technology. Implementations of the OSI model stip- 
ulate communication between layers on two processors and an interface for interlayer 
communication on one processor. Physical communication occurs only at layer 1. All 
other layers communicate downward (or upward) to lower (or higher) levels in steps 


through protocol stacks. 


The following briefly describes the seven layers of the OSI model: 


1. Physical layer. The physical layer provides the interface with physical media. The 
interface itself is a mechanical connection from the device to the physical medium 
used to transmit the digital bit stream. The mechanical specifications do not specify 
the electrical characteristics of the interface, which will depend on the medium being 
used and the type of interface. This layer is responsible for converting the digital 
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data into a bit stream for transmission over the network. The physical layer includes 
the method of connection used between the network cable and the network adapter, 
as well as the basic communication stream of data bits over the network cable. The 
physical layer is responsible for the conversion of the digital data into a bit stream 
for transmission when using a device such as a modem, and even light, as in fibre 
optics. For example, when using a modem, digital signals are converted into analogue 
audible tones which are then transmitted at varying frequencies over the telephone 
line. The OSI model does not specify the medium, only the operative functionality 
for a standardised communication protocol. The transmission media layer specifies 
the physical medium used in constructing the network, including size, thickness and 
other characteristics. 


Data link layer. The data link layer represents the basic communication link that exists 
between computers and is responsible for sending frames or packets of data without 
errors. The software in this layer manages transmissions, error acknowledgement and 
recovery. The transceivers are mapped data units to data units to provide physical error 
detection and notification and link activation/deactivation of a logical communication 
connection. Error control refers to mechanisms to detect and correct errors that occur 
in the transmission of data frames. Therefore, this layer includes error correction, so 
when a packet of data is received incorrectly, the data link layer makes system send 
the data again. The data link layer is also defined in the IEEE 802.2 logical link 
control specifications. 

Data link control protocols are designed to satisfy a wide variety of data link 
requirements: 


— High-level Data Link Control (HDLC) developed by the International Organisa- 
tion for Standardisation (ISO 3309, ISO 4335); 

— Advanced Data Communication Control Procedures (ADCCP) developed by the 
American National Standards Institute (ANSI X3.66); 

— Link Access Procedure, Balanced (LAP-B) adopted by the CCITT as part of its 
X.25 packet-switched network standard; 

— Synchronous Data Link Control (SDLC) is not a standard, but is in widespread 
use. There is practically no difference between HDLC and ADCCP. Both LAP-B 
and SDLC are subsets of HDLC, but they include several additional features. 


Network layer. The network layer is responsible for data transmission across networks. 
This layer handles the routing of data between computers. Routing requires some 
complex and crucial techniques for a packet-switched network design. To accomplish 
the routing of packets sending from a source and delivering to a destination, a path 
or route through the network must be selected. This layer translates logical network 
addressing into physical addresses and manages issues such as frame fragmentation 
and traffic control. The network layer examines the destination address and determines 
the link to be used to reach that destination. It is the borderline between hardware 
and software. At this layer, protocol mechanisms activate data routing by provid- 
ing network address resolution, flow control in terms of segmentation and blocking 
and collision control (Ethernet). The network layer also provides service selection, 
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connection resets and expedited data transfers. The Internet Protocol (IP) runs at 
this layer. 

The IP was originally designed simply to interconnect as many sites as possible 
without undue burdens on the type of hardware and software at different sites. To 
address the shortcomings of the IP and to provide more a reliable service, the Trans- 
mission Control Protocol (TCP) is stacked on top of the IP to provide end-to-end 
service. This combination is known as TCP/IP and is used by most Internet sites 
today to provide a reliable service. 


Transport layer. The transport layer is responsible for ensuring that messages are 
delivered error-free and in the correct sequence. This layer splits messages into smaller 
segments if necessary and provides network traffic control of messages. Traffic con- 
trol is a technique for ensuring that a source does not overwhelm a destination with 
data. When data is received, a certain amount of processing must take place before 
the buffer is clear and ready to receive more data. In the absence of flow control, the 
receiver's buffer may overflow while it is processing old data. The transport layer, 
therefore, controls data transfer and transmission. This software is called Transmis- 
sion Control Protocol (TCP), common on most Ethernet networks, or System Packet 
Exchange (SPE), a corresponding Novell specification for data exchange. Today most 
Internet sites use the TCP/IP protocol along with ICMP to provide a reliable service. 


Session layer. The session layer controls the network connections between the com- 
puters in the network. The session layer recognises nodes on the LAN and sets up 
tables of source and destination addresses. It establishes a handshake for each session 
between different nodes. Technically, this layer is responsible for session connection 
(i.e. for creating, terminating and maintaining network sessions), exception reporting, 
coordination of send/receive modes and data exchange. 


Presentation layer. The presentation layer is responsible for the data format, which 
includes the task of hashing the data to reduce the number of bits (hash code) that will 
be transferred. This layer transfers information from the application software to the 
network session layer to the operating system. The interface at this layer performs data 
transformations, data compression, data encryption, data formatting, syntax selection 
(i.e. ASCII, EBCDIC or other numeric or graphic formats), and device selection and 
control. It actually translates data from the application layer into the format used 
when transmitting across the network. On the receiving end, this layer translates the 
data back into a format that the application layer can understand. 


Application layer. The application layer is the highest layer defined in the OSI model 
and is responsible for providing user-layer applications and network management 
functions. This layer supports identification of communicating partners, establishes 
authority to communicate, transfers information and applies privacy mechanisms and 
cost allocations. It is usually a complex layer with a client/server, a distributed 
database, data replication and synchronisation. The application layer supports file 
services, print services, remote login and e-mail. The application layer is the network 
system software that supports user-layer applications, such as word or data processing, 
CAD/CAM, document storage and retrieval and image scanning. 
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1.4 TCP/IP Model 


A protocol is a set of rules governing the way data will be transmitted and received over 
data communication networks. Protocols are then the rules that determine everything about 
the way a network operates. Protocols must provide reliable, error-free communication 
of user data as well as a network management function. Therefore, protocols govern how 
applications access the network, the way that data from an application is divided into 
packets for transmission through cable, and which electrical signals represent data on a 
network cable. 

The OSI model, defined by a seven-layer architecture, is partitioned into a vertical set 
of layers, as illustrated in Figure 1.2. The OSI model is based on open systems and peer- 
to-peer communications. Each layer performs a related subset of the functions required to 
communicate with another system. Each system contains seven layers. If a user or appli- 
cation entity A wishes to send a message to another user or application entity B, it invokes 
the application layer (layer 7). Layer 7 (corresponding to application A) establishes a peer 
relationship with layer 7 of the target machine (application B), using a layer 7 protocol. 

In an effort to standardise a way of looking at network protocols, the TCP/IP four-layer 
model is created with reference to the seven-layer OSI model, as shown in Figure 1.3. The 
protocol suite is designed in distinct layers to make it easier to substitute one protocol for 
another. The protocol suite governs how data is exchanged above and below each protocol 
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Figure 1.3 The TCP/IP model and Internet protocol suite. 
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layer. When protocols are designed, specifications set out how a protocol exchanges data 
with a protocol layered above or below it. 

Both the OSI model and the TCP/IP layered model are based on many similarities, but 
there are philosophical and practical differences between the two models. However, they 
both deal with communications among heterogeneous computers. 

Since TCP was developed before the OSI model, the layers in the TCP/IP protocol 
model do not exactly match those in the OSI model. The important fact is the hierarchical 
ordering of protocols. The TCP/IP model is made up of four layers: application layer, 
transport layer, Internet layer and network access layer. These will be discussed below. 


1.4.1. Network Access Layer 


The network access layer contains protocols that provide access to a communication 
network. At this layer, systems are interfaced to a variety of networks. One function of 
this layer is to route data between hosts attached to the same network. The services to 
be provided are flow control and error control between hosts. The network access layer 
is invoked either by the Internet layer or the application layer. This layer provides the 
device drivers that support interactions with communications hardware such as the token 
ring or Ethernet. The IEEE token ring, referred to as the Newhall ring, is probably the 
oldest ring control technique and has become the most popular ring access technique in 
the USA. The Fiber Distributed Data Interface (FDDI) is a standard for a high-speed ring 
LAN. Like the IEEE 802 standard, FDDI employs the token ring algorithm. 


1.4.2 Internet Layer 


The Internet layer provides a routing function. Therefore, this layer consists of the pro- 
cedures required within hosts and gateways to allow data to traverse multiple networks. 
A gateway connecting two networks relays data between networks using an internetwork 
protocol. This layer consists of the Internet Protocol (IP) and the Internet Control Message 
Protocol (ICMP). 


1.4.3 Transport Layer 


The transport layer delivers data between two processes on different host computers. A 
protocol entity at this level provides a logical connection between higher-level entities. 
Possible services include error and flow controls and the ability to deal with control signals 
not associated with a logical data connection. This layer contains the Transmission Control 
Protocol (TCP) and the User Datagram Protocol (UDP). 


1.4.4 Application Layer 


This layer contains protocols for resource sharing and remote access. The application layer 
actually represents the higher-level protocols that are used to provide a direct interface 
with users or applications. Some of the important application protocols are File Transfer 
Protocol (FTP) for file transfers, HyperText Transfer Protocol (HTTP) for the World Wide 
Web, and Simple Network Management Protocol (SNMP) for controlling network devices. 
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The Domain Naming Service (DNS) is also useful because it is responsible for converting 
numeric IP addresses into names that can be more easily remembered by users. Many 
other protocols dealing with the finer details of applications are included in this application 
layer. These include Simple Mail Transport Protocol (SMTP), Post Office Protocol (POP), 
Internet Mail Access Protocol IMAP), Internet Control Message Protocol (ICMP) for e- 
mail, Privacy Enhanced Mail (PEM), Pretty Good Privacy (PGP) and Secure Multimedia 
Internet Mail Extensions (S/MIME) for e-mail security. All protocols contained in the 
TCP/IP suite are fully described in Chapter 2. 


2 


TCP/IP Suite and Internet Stack 
Protocols 


The Internet protocols consist of a suite of communication protocols, of which the two best 
known are the Transmission Control Protocol (TCP) and the Internet Protocol (IP). The 
TCP/IP suite includes not only lower-layer protocols (TCP, UDP, IP, ARP, RARP, ICMP 
and IGMP), but also specifies common applications such as www, e-mail, domain naming 
service, login and file transfer. Figure 1.3 in Chapter 1 depicts many of the protocols of 
the TCP/IP suite and their corresponding OSI layer. 

It may not be important for the novice to understand the details of all protocols, but it 
is important to know which protocols exist, how they can be used, and where they belong 
in the TCP/IP suite. 

This chapter addresses various layered protocols in relation to Internet security, and 
shows which are available for use with which applications. 


2.1 Network Layer Protocols 


At the network layer in the OSI model, TCP/IP supports the IP. IP contains four supporting 
protocols: ARP, RARP, ICMP and IGMP. Each of these protocols is described below. 


2.1.1 Internet Protocol (IP) 


The Internet Protocol (IP) is a network layer (layer 3 in the OSI model or the Internet 
layer in the TCP/IP model) protocol which contains addressing information and some 
control information to enable packets to be controlled. IP is well documented in RFC 791 
and is the basic communication protocol in the Internet protocol suite. 

IP specifies the exact format of all data as it passes across the Internet. IP software 
performs the routing function, choosing the path over which data will be sent. IP includes 
a set of rules that enbody the idea of unreliable packet delivery. IP is an unreliable 
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and connectionless datagram protocol. The service is called unreliable because delivery 
is not guaranteed. The service is called connectionless because each packet is treated 
independently from all others. If reliability is important, IP must be paired with a reliable 
protocol such as TCP. However, IP does its best to get a transmission through to its 
destination, but carries no guarantees. 

IP transports the datagram in packets, each of which is transported separately. Data- 
grams can travel along different routes and can arrive out of sequence or be duplicated. 
IP does not keep track of the routes taken and has no facility for reordering datagrams 
once they arrive at their destination. In short, the packet may be lost, duplicated, delayed 
or delivered out of order. 

IP is a connectionless protocol designed for a packet switching network which uses the 
datagram mechanism. This means that each datagram is separated into segments (packets) 
and is sent independently following a different route to its destination. This implies that if 
a source sends several datagrams to the same destination, they could arrive out of order. 
Even though IP provides limited functionality, it should not be considered a weakness. 
Figure 2.1 shows the format of an IP datagram. Since datagram processing occurs in 
software, the content of an IP datagram is not constrained by any hardware. 


2.1.1.1 IP Datagrams 


Packets in the IP layer are called datagrams. Each IP datagram consists of a header (20 
to 60bytes) and data. The IP datagram header consists of a fixed 20-byte section and 
a variable options section with a maximum of 40bytes. The Internet header length is 
the total length of the header, including any option fields, in 32-bit words. The minimum 
value for the Internet header length is 5 (five 32-bit words or 20 bytes of the IPv4 header). 
The maximum permitted length of an IP datagram is 65 536 bytes. However, such large 
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Figure 2.1 IP datagram format. 
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packets would not be practical, particularly on the Internet where they would be heavily 
fragmented. RFC 791 states that all hosts must accept IP datagrams up to 576 bytes. An 
IPv4 datagram consists of three primary components. The header is 20 bytes long and 
contains a number of fields. The option is a variable length set of fields, which may or 
may not be present. Data is the encapsulated payload from the higher level, usually a 
whole TCP segment or UDP datagram. The datagram header contains the source and 
destination IP addresses, fragmentation control, precedence, a checksum used to detect 
transmission errors, and IP options to record routing information or gathering timestamps. 
A brief explanation of each field in an IP datagram is described below. 


Version (VER, 4 bits): Version 4 of the Internet Protocol (IPv4) has been in use since 
1981, but Version 6 (IPv6 or IPng) will soon replace it. The first four-bit field in a 
datagram contains the version of the IP protocol that was used to create the datagram. 
It is used to verify that the sender, receiver and any routers in between them agree on 
the format of datagram. In fact, this field is an indication to the IP software running in 
the processing machine that it is required to check the version field before processing 
a datagram to ensure it matches the format the software expects. 


Header length (HLEN, 4 bits): This four-bit field defines the total length of the IPv4 
datagram header measured in 32-bit words. This field is needed because the length of 
the header varies between 20 to 60 bytes. All fields in the header have fixed lengths 
except for the IP options and corresponding padding field. 


Type of service (TOS, & bits): This eight-bit field specifies how the datagram should be 
handled by the routers. This TOS field is divided into two subfields: precedence (3 bits) 
and TOS (5 bits) as shown in Figure 2.2. Precedence is a three-bit subfield with values 
ranging from 0 (000 in binary, normal precedence) to 7 (111 in binary, network 
control), allowing senders to indicate the importance of each datagram. Precedence 
defines the priority of the datagram in issues such as congestion. If a router is congested 
and needs to discard some datagrams, those datagrams with lowest precedence are 
discarded first. A datagram in the Internet used for network management is much more 
important than a datagram used for sending optional information to a group of users. 
Many routers use a precedence value of 6 or 7 for routing traffic to make it possible 
for routers to exchange routing information even when networks are congested. At 
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Figure 2.2 The eight-bit service type field. 
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present, the precedence subfield is not used in version 4, but it is expected to be 
functional in future versions. 

The TOS field is a five-bit subfield, each bit having a special meaning. Bits D, T, 
R and C specify the type of transport desired for the datagram. When they are set, the 
D bit requests low delay, the T bit requests high throughput, the R bit requests high 
reliability and the C bit requires low cost. Of course, it may not be possible for the 
Internet to guarantee the type of transport requested. Therefore, the transport request 
may be thought of as a hint to the routing algorithms, not as a demand. Datagrams 
carrying keystrokes from a user to a remote computer could set the D bit to request that 
they be delivered as quickly as possible, while datagrams carrying a bulk file transfer 
could have the T bit set requesting that they travel across the high-capacity path. 

Although a bit in TOS bits can be either 0 or 1, only one bit can have the value 1 
in each datagram. The bit patterns and their descriptions are given in Table 2.1. 

In the late 1990s, the IETF redefined the meaning of the eight-bit service type field 
to accommodate a set of differentiated services (DS). The DS defines that the first 
six bits comprise a codepoint and the last two bits are left unused. A codepoint value 
maps to an underlying service through an array of pointers. Although it is possible 
to design 64 separate services, designers suggest that a given router will only have a 
few services, and multiple codepoints will map to each service. When the last three 
bits of the codepoint field contains zero, the precedence bits define eight broad classes 
of service that adhere to the same guidelines as the original definition. When the last 
three bits are zero, the router must map a codepoint with precedence 6 or 7 into the 
higher-priority class and other codepoint values into the lower priority class. 


Overall length (16 bits): The IPv4 datagram format allots 16 bits to the total length 
field, limiting the datagram to at most 65 535 bytes. This 16-bit field defines the total 
length (header plus data) of the IP datagram in bytes. To find the data length coming 
from the upper layer, subtract the header length from the total length. Since the 
field length is 16 bits, the total length of the IP datagram is limited to 2'°—1= 
65 535 bytes, of which 20 to 60 bytes are the header and the rest are data from the 
upper layer. In practice, some physical networks are unable to encapsulate a datagram 
of 65535 bytes in the process of fragmentation. 


Identification (ID, 16 bits): This 16-bit field specifies to identify a datagram originating 
from the source host. The ID field is used to help a destination host to reassemble 
a fragmented packet. It is set by the sender and uniquely identifies a specific IP 
datagram sent by a source host. The combination of the identification and source 


Table 2.1 Type of service (TOS) 


TOS bit Description 
0000 Normal (default) 
0001 Minimise cost 
0010 Maximise reliability 
0100 Maximise throughput 


1000 Minimise delay 
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IP address must uniquely define the same datagram as it leaves the source host. To 
guarantee uniqueness, the IP protocol uses a counter to label the datagrams. When a 
datagram is fragmented, the value in the identification field is copied in all fragments. 
Hence, all fragments have the same identification number, which is the same as in the 
original datagram. The identification number helps the destination in reassembling the 
datagram. RFC 791 suggests that the ID number is set by the higher-layer protocol, 
but in practice it tends to be set by IP. 


Flags (three bits): This three-bit field is used in fragmentation. The flag field is three 
bits long. Bit 0: Reserved, Bit 1: May fragment or may not fragment, Bit 2: Last 
fragment or more fragments. The first bit is reserved. The second bit is called the 
‘don’t fragment’ bit. If its value is 1, don’t fragment the datagram. If it cannot pass 
the datagram through any available physical network, it discards the datagram and 
sends an ICMP error message to the source host. The third bit is called the ‘more 
fragment’ bit. If its value is 1, it means the datagram is not the last fragment; there are 
more fragments to come. If its value is 0, it means that it is the last or only fragment. 


Fragmentation offset (13 bits): The small pieces into which a datagram is divided are 
called fragments, and the process of dividing a datagram is known as fragmentation. 
This 13-bit field denotes an offset to a non-fragmented datagram, used to reassemble 
a datagram that has become fragmented. This field shows the relative position of each 
fragment with respect to the whole datagram. The offset states where the data in a 
fragmented datagram should be placed in the datagram being reassembled. The offset 
value for each fragment of a datagram is measured in units of eight bytes, starting at 
offset zero. Since the length of the offset field is only 13 bits, it cannot represent a 
sequence of bytes greater than 2!3 — 1 = 8191. 

Suppose a datagram with a data size of x < 8191 bytes is fragmented into i frag- 
ments. The bytes in the original datagram are numbered from 0 to (x — 1) bytes. If the 
first fragment carries bytes from 0 to x;, then the offset for this fragment is 0/8 = 0. 
If the second fragment carries (x; + 1) bytes to x2 bytes, then the offset value for this 
fragment is (x, + 1)/8. If the third fragment carries bytes x2 + 1 to x3, then the offset 
value for the third fragment is (x2 + 1)/8. Continue this process within the range under 
8191 bytes. Thus, the offset value for these fragments is 0, (x;_; + 1)/8,i = 2,3,.... 
Consider what happens if a fragment itself is fragmented. In this case the value of the 
offset field is always relative to the original datagram. 

Fragment size is chosen such that each fragment can be sent across the network in 
a single frame. Since IP represents the offset of the data in multiples of eight bytes, 
the fragment size must be chosen to be a multiple of eight. Of course, choosing the 
multiple of eight bytes nearest to the network’s maximum transfer unit (MTU) does 
not usually divide the datagram into equal-sized fragments; the last piece or fragment 
is often shorter than the others. The MTU is the maximum size of a physical packet 
on the network. If datagram, including the 20-byte IP header, to be transmitted is 
greater than the MTU, then the datagram is fragmented into several small fragments. 
To reassemble the datagram, the destination must obtain all fragments starting with 
the fragment that has offset 0 through the fragment with the highest offset. 
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e Time to live (TTL, 8 bits): A datagram should have a limited lifetime in its travel 
through an Internet. This eight-bit field specifies how long (in number of seconds) the 
datagram is allowed to remain in the Internet. 

Routers and hosts that process datagrams must decrement this TTL field as time 
passes and remove the datagram from the Internet when its time expires. Whenever 
a host computer sends the datagram to the Internet, it sets a maximum time that the 
datagram should survive. When a router receives a datagram, it decrements the value 
of this field by one. Whenever this value reaches zero after being decremented, the 
router discards the datagram and returns an error message to the source. 


e Protocol (eight bits): This eight-bit field defines the higher-level protocol that uses the 
services of the IP layer. An IP datagram can encapsulate data from several higher-level 
protocols such as TCP, UDP, ICMP and IGMP. This field specifies the final desti- 
nation protocol to which the IP datagram should be delivered. Since the IP protocol 
multiplexes and demultiplexes data from different higher-level protocols, the value 
of this field helps the demultiplexing process when the datagram arrives at its final 
destination. 


e Header checksum (16 bits): The error detection method used by most TCP/IP protocols 
is called the checksum. This 16-bit field ensures the integrity of header values. The 
checksum (redundant bits added to the packet) protects against errors which may occur 
during the transmission of a packet. 

At the sender, the checksum is calculated and the result obtained is sent with the 
packet. The packet is divided into n-bit sections. These sections are added together 
using arithmetic in such a way that the sum also results in n bits. The sum is then 
complemented to produce the checksum. 

At the receiver, the same calculation is repeated on the whole packet including the 
checksum. The received packet is also divided into n-bit sections. The sum is then 
complemented. The final result will be zero if there are no errors in the data during 
transmission or processing. If the computed result is satisfactorily met, the packet is 
accepted; otherwise it is rejected. 

It is important to note that the checksum only applies to values in the IP header, 
and not in the data. Since the header usually occupies fewer bytes than the data, the 
computation of header checksums will lead to reduced processing time at routers. 


Example 2.1 Consider a checksum calculation for an IP header without options. The 
header is divided into 16-bit fields. All the fields are added and the sum is complemented 
to obtain the checksum. The result is inserted in the checksum field. 
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4, 5, and 0: 
28: 

1: 

O and 0: 

4 and 17: 
0: 

10.12: 

14.5: 

12.6: 

7.9: 


Sum: 


*Checksum: 


01000101 
00000000 
00000000 
00000000 
00000100 
00000000 
00001010 
00001110 
00001100 
00000111 


01110100 
10001011 


00000000 
00011100 
00000001 
00000000 
00010001 
00000000 
00001100 
00000101 
00000110 
00001001 


01001110 
10110001 


Source IP address (32 bits): This 32-bit field specifies the IP address of the sender of 
the IP datagram. 


Destination IP address (32 bits): This 32-bit field designates the IP address of the host 
to which this datagram is to be sent. Source and destination IP addresses are discussed 
in more detail in Section 2.1.1.2, IP Addressing. 


Options (variable length): The IP header option is a variable length field, consisting 
of zero, one or more individual options. This field specifies a set of fields, which may 
or may not be present in any given datagram, describing specific processing that takes 
place on a packet. RFC 791 defines a number of option fields with additional options 
defined in RFC 3232. The most common options include: 


— The security option tends not to be used in most commercial networks. Refer to 
RFC 1108 for more details. 

— A record route option is used to record the Internet routers that handle the data- 
gram. Each router records its IP address in the option field, which can be useful 
for tracing routing problems. 

— The timestamp option is used to record the time of datagram processing by a 
router. This option requests each router to record both the router address and the 
time. This option is useful for debugging router problems. 

— A source routing option is used by the source to predetermine a route for the 
datagram as it travels through the Internet. This option enables a host to define 
the routers the packet is to be transmitted through. Dictation of a route by the 
source is useful for several reasons. The sender can choose a route with a specific 
type of service, such as minimum delay or maximum throughput. It may also 
choose a route that is safer or more reliable for the sender’s purpose. Because 
the option fields are of variable length, it may be necessary to add additional 
bytes to the header to make it a whole number of 32-bit words. Since the IP 
option fields represent a significant overhead, they tend not to be used, especially 
for IP routers. If required, additional padding bytes are added to the end of any 
specific options. 
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2.1.1.2 IP Addressing 


Addresses belonging to three different layers of TCP/IP architecture are shown in Table 2.2 
below. 


e Physical (local or link) address: At the physical level, the hosts and routers are recog- 
nised by their physical addresses. The physical address is the lowest-level address which 
is specified as the node or local address defined by LAN or WAN. This local address 
is included in the frame used by the network access layer. A local address is called a 
physical address because it is usually (but not always) implemented in hardware. Ether- 
net or token ring uses a six-byte address that is imprinted on the network interface card 
(NIC) installed in the host or router. The physical address should be unique locally, but 
not necessary universally. Physical addresses can be either unicast (one single recipi- 
ent), multicast (a group of recipients), or broadcast (all recipients on the network). The 
physical addresses will be changed as a packet moves from network to network. 


e JP address: An IP address is called a logical address at the network level because it 
is usually implemented in software. A logical address identifies a host or router at the 
network level. TCP/IP calls this logical address an IP address. Internet addresses can be 
either unicast, multicast or broadcast. IP addresses are essentially needed for universal 
communication services that are independent of underlying physical networks. IP 
addresses are designed for a universal addressing system in which each host can 
be identified uniquely. An Internet address is currently a 32-bit address which can 
uniquely define a host connected to the Internet. 


e Port address: The data sequences need the IP address and the physical address to 
move data from a source to the destination host. In fact, delivery of a packet to a 
host or router requires two levels of addresses, logical and physical. Computers are 
devices that can run multiple processes at the same time. For example, computer A 
communicates with computer B using TELNET. At the same time, computer A can 
communicate with computer C using File Transfer Protocol (FTP). If these processes 
occur simultaneously, we need a method to label different processes. In TCP/IP archi- 
tecture, the label assigned to a process is called a port address. A port address in 
TCP/IP is 16 bits long. 

The Internet Assigned Numbers Authority (IANA) manages the well-known port 
numbers between | and 1023 for TCP/IP services. Ports between 256 and 1023 were 
normally used by UNIX systems for UNIX-specific services, but are probably not 
found on other operating systems. 


Table 2.2. TCP/IP architecture and corresponding addresses 


Layer TCP/IP Protocol Address 

Application HTTP, FTP, SMTP Port address 
DNS and other protocols 

Transport TCP, UDP — 

Internet IP, ICMP, IGMP IP address 


Network access Physical network Physical (link) address 
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Servers are normally known by their port number. For few examples, every TCP/IP 
implementation that provides a File Transfer Protocol (FTP) server provides that ser- 
vice on TCP port 21. Telnet is a TCP/IP standard with a port number of 23 and can 
be implemented on almost any operating system. Hence, every Telnet server is on 
TCP port 23. Every implementation of the Trivial File Transfer Protocol (TFTP) is 
on UDP port 69. The port number for the Domain Name System is on TCP port 53. 


Addressing schemes 


Each IP address is made of two parts in such a way that the netid defines a 
network and the hostid identifies a host on that network. An IP address is usually 
written as four decimal integers separated by decimal points i.e. 239.247.135.93. If 
this IP address changes from decimal-point notation to binary form, it becomes 
11101111 11110111 10000111 01011101. Thus, we see that each integer gives the value 
of one octet (byte) of the IP address. 

IP addresses are divided into five different classes: A, B, C, D and E. Classes A, B 
and C differ in the number of hosts allowed per network. Class D is used for multicasting 
and class E is reserved for future use. Table 2.3 shows the number of networks and 
hosts in five different IP address classes. Note that the binary numbers in brackets denote 
class prefixes. 

The relationship between IP address classes and dotted decimal numbers is summarised 
in Table 2.4, which shows the range of values for each class. The use of leading bits as 
class prefixes means that the class of a computer’s network can be determined by the 
numerical value of its address. 

A number of IP addresses have specific meanings. The address 0.0.0.0 is reserved 
and 224.0.0.0 is left unused. Addresses in the range 10.0.0.0 through to 10.255.255.255 
are available for use in private intranets. Addresses in the range 240.0.0.0 through to 
255.255.255.255 are class E addresses and are reserved for future use when new protocols 
are developed. Address 255.255.255.255 is the broadcast address, used to reach all systems 


Table 2.3. Number of networks and hosts in each address class 


Address Netid Hostid Number of 
Class Networks and Hosts 
Netid Hostid 

A (0) First octet Three octets 27-2=126 2%—2= 16777214 
(8 bits) (24 bits) 

B (10) Two octets Two octets 24 — 16384 2!6_ 9 = 65534 
(16 bits) (16 bits) 

C (110) Three octets Last octet 27! — 2097152 28 —2 = 254 
(24 bits) (8 bits) 

D (1110) _ —_ No netid No hostid 

E (1111) — — No netid No hostid 


D (1110): Multicast address only 
E (1111): Reserved for special use 
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Table 2.4 Dotted decimal values corresponding to IP 
address classes 


Class Prefix Address range 

Lowest Highest 
A 0 0.0.0.0 127.255.255.255 
B 10 128.0.0.0 191.255.255.255 
C 110 192.0.0.0 223.255.255.255 
D 1110 224.0.0.0 239.255.255.255 
E 1111 240.0.0.0 255.255.255.255 


on a local link. Although the multicast address of class D may extend from 224.0.0.0 
to 239.255.255.255, address 224.0.0.0 is never used and 224.0.0.1 is assigned to the 
permanent group of all IP hosts, including gateways. A packet addressed to 224.0.0.1 
will reach all multicast hosts on the directly connected network. In addition, a hostid of 
255 specifies all systems within a given subnet, and a subnetid of 255 specifies all subnets 
within a network. 

When an IP address is given, the address class can be determined. Once the address 
class is determined, it is easy to extract the netid and hostid. Figure 2.3 shows how to 
extract the netid and hostid by the octets and how to determine the number of networks 
and hosts. 

According to Table 2.3 or Figure 2.3, the two-layer hierarchy established in IP address 
pairs (netid, hostid) lacks the flexibility needed for any sophisticated size of network. 
To begin with, a class A network can contain 16777214 host identifiers (hostids). These 
are too many identifiers to configure and manage as an address space. Many of these 
hosts are likely to reside on various locally administered LANs, with different media and 
data-link protocols, different access needs and, in all likelihood, different geographical 
locations. In fact, the IP addressing scheme has no way to reflect these subdivisions within 
a large organisation WAN. In addition, class A, B and C network identifiers (netids) are 
a limited and scarce resource, whose use under the class addressing scheme was often 
in efficient. In reality, many medium-sized organisations found class C hostids to be too 
small, containing fewer than 256 hosts. On the other hand, they often requested class B 
identifiers despite having far fewer than 65 534 hostids. As a result, many of the (netid, 
hostid) pairs were allocated but unused, being superfluous to the network owner and 
unusable by other organisations. 


Subnetting and supernetting 


The increasing number of hosts connected to the Internet and restrictions imposed by the 
Internet addressing scheme led to the idea of subnetting and supernetting. In subnetting, 
one large network is divided into several smaller subnetworks, and class A, B and C 
addresses can be subnetted. In supernetting, several networks are combined into one large 
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Figure 2.3. The number of networks and hosts corresponding to IP address classes. 


network, bringing several class C addresses to create a large range of addresses. Classes 
A, B and C in IP addressing are designed by two levels of hierarchy such that a portion 
of the address indicates a netid and a portion of address indicates a hostid on the network. 

Consider an organisation with two-level hierarchical addressing. With this scheme, the 
organisation has one network with many hosts because all of the hosts are at the same level. 
Subnetting is accomplished by the further division of a network into smaller subnetworks. 
When a network is subnetted, it has three portions: netid, subnetid and hostid. When the 
datagram arrives at a router, it knows that the first two octets (bytes) denote netid and the 
last two octets (bytes) define subnetid and hostid, respectively. For example, for a 32-bit 
IP address of 141.14.5.23, the router uses the first two octets (141.14) as the netid, the 
third octet (5) as the subnetid, and the fourth octet (23) as the hostid. Thus, the routing 
of an IP datagram now involves three steps: delivery to the network site, delivery to the 
subnetwork and delivery to the host. 
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Example 2.2. Consider the IP address in decimal point notation (141.14.2.21). 


Without subnetting (level 2 of the hierarchy) 
netid hostid 


141.14 . 


Network access Host access 


With subnetting (level 3 of the hierarchy) 


netid subnetid hostid 
141.14] . : 
Subnetwork access Host access 


To accommodate the growth of address space, by 1993 the supernetting scheme had 
begun to take an approach that is complementary to subnet addressing. Supernetting 
allows addresses to assign a single organisation to span multiple classed prefixes. A 
class C address cannot accommodate more than 254 hosts and a class B address has 
sufficient bits to make subnetting convenient. Therefore, one solution to this is supernet- 
ting. An organisation that needs 1000 addresses can be granted four class C addresses. 
The organisation can then use these addresses in one supernetwork. Suppose an organ- 
isation requests a class B address and intends to subnet using the third octet as a 
subnet field. Instead of a single class B number, supernetting assigns the organisation 
a block of 256 contiguous class C numbers that the organisation can then assign to 
physical networks. 


Mapping by mask 


Masking is a process that extracts the physical network address from an IP address. 
Masking can be accomplished regardless of whether it has subnetting or not. Consider 
two cases in which a network is either subnetted or is not. With no subnetting, masking 
extracts the network address from an IP address, while with subnetting, masking also 
extracts the subnetwork address from an IP address. The masking operation can be done 
by performing a 32-bit IP address on another 32-bit mask. A masking pattern consists of 
a contiguous string of 1s and Os. The contiguous mask means a string of Is precedes a 
string of Os. To get either the network address or the subnet address, the logical AND 
operation with the bit-by-bit basis must be applied on the IP address and the mask. An 
example is shown below. 


Example 2.3 Suppose a 32-bit IP address is 141.14.5.23 and the mask 255.255.0.0. 
Find the network address and subnetwork address. 
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netid hostid 


141.14] . <q Without subnetting 


Network access Host access 


netid subnetid hostid 
141.14] . . <+_— With subnetting 
Subnetwork access Host access 


(1) Without subnetting 


IP address : 10001101 00001110 00000101 00010111 
Mask : 11111111 11111111 00000000 00000000 


Network address :{10001101 00001110} 00000000 00000000 
(2) With subnetting 


IP address : 10001101 00001110 00000101 00010111 
Mask > T1111111 11111111 11111111 00000000 


Network address :[10001101 00001110 00000101] 00000000 


Mapping of a logical address to a physical address can be static or dynamic. Static map- 
ping involves a list of logical and physical address correspondences, but maintenance of 
the list requires high overhead. Address Resolution Protocol (ARP) is a dynamic mapping 
method that finds a physical address given a logical address. An ARP request is broad- 
cast to all devices on the network, while an ARP reply is unicast to the host requesting 
the mapping. Reverse Address Resolution Protocol (RARP) is a form of dynamic map- 
ping in which a given physical address is associated with a logical addresses. ARP and 
RARP use unicast and broadcast physical addresses. These subjects will be discussed in 
a later section. 





2.1.1.3 IP Routing 


In a connectionless packet delivery system, the basic unit of transfer is the IP datagram. 
The routing problem is characterised by describing how routers forward IP datagrams and 
deliver them to their destinations. In a packet switching system, ‘routing’ refers to the 
process of choosing a path over which to send packets. Unlike routing within a single 
network, the IP routing must choose the appropriate algorithm for how to send a datagram 
across multiple physical networks. In fact, routing over the Internet is generally difficult 
because many computers have multiple physical network connections. 

To understand IP routing, a TCP/IP architecture should be reviewed completely. The 
Internet is composed of multiple physical networks interconnected by routers. Each router 
has direct connections to two or more networks, while a host usually connects directly 
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to one physical network. However, it is possible to have a multihomed host connected 
directly to multiple network. 

Packet delivery through a network can be managed at any layer in the OSI stack model. 
The physical layer is governed by the Media Access Control (MAC) address; the data 
link layer includes the Logical Link Control (LLC); and the network layer is where most 
routing takes place. 


Delivery 


The delivery of an IP packet to its final destination is accomplished by means of either 
direct or indirect delivery. Direct delivery occurs when the source and destination of the 
packet are located on the same physical network. The sender can easily determine whether 
the delivery is direct or not by extracting the network (IP) address of the destination packet 
and comparing this address with the addresses of the networks to which it is connected. 
If a match is found, the delivery is direct. In direct delivery, the sender uses the senders 
IP address to find the destination physical address. This mapping process can be done by 
Address Resolution Protocol (ARP). 

If the destination host is not on the same network as the source host, the packet will be 
delivered indirectly. In an indirect delivery, the packet goes from router to router through 
a number of networks until it reaches one that is connected to the same physical network 
as its final destination. Thus, the last delivery is always a direct delivery, which always 
occurs after zero or more indirect deliveries. In an indirect delivery, the sender uses the 
destination IP address and a routing table to find the IP address of the next router to 
which the packet should be delivered. The sender then uses the ARP to find the physical 
address of the next router. 


2.1.2 Address Resolution Protocol (ARP) 


IP (logical) addresses are assigned independently from physical (hardware) addresses. 
The logical address is called a 32-bit IP address, and the physical address is a 48-bit 
MAC address in Ethernet and token ring protocols. The delivery of a packet to a host 
or a router requires two levels of addressing, such as logical (IP) address and physical 
(MAC) addresses. When a host or a router has an IP datagram forwarding to another host 
or router, it must know the logical IP address of the receiver. Since the IP datagram is 
encapsulated in a form to be passed through the physical network (such as a LAN), the 
sender needs the physical MAC address of the receiver. 

Mapping of an IP address to a physical address can be done by either static or dynamic 
mapping. Static mapping means creating a table that associates an IP address with a 
physical address. But static mapping has some limitations because table lookups are 
inefficient. As a consequence, static mapping creates a huge overhead on the network. 
Dynamic mapping can employ a protocol to find the other. Two protocols (ARP and 
RARP) have been designed to perform dynamic mapping. When a host needs to find 
the physical address of another host or router on its network, it sends an ARP query 
packet. The intended recipient recognises its IP address and sends back an ARP response 
which contains the recipient IP and physical addresses. An ARP request is broadcast to all 
devices on the network, while an ARP reply is unicast to the host requesting the mapping. 
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Figure 2.4 ARP dynamic mapping. 


Figure 2.4 shows an example of simplified ARP dynamic mapping. Let a host or router 
call a machine. A machine uses ARP to find the physical address of another machine by 
broadcasting an ARP request. The request contains the IP address of the machine for which 
a physical address is needed. All machines (M1, M2, M3, ...) on the network receive an 
ARP request. If the request matches a M2 machine’s IP address, the machine responds 
by sending a reply that contains the requested physical address. Note that Ethernet uses 
the 48-bit address of all 1’s (FFFFFFFFFFFF) as the broadcast address. 

A proxy ARP is an ARP that acts on behalf of a set of hosts. Proxy ARP can be used 
to create a subnetting effect. In proxy ARP, a router represents a set of hosts. When an 
ARP request seeks the physical address of any host in this set, the router sends its own 
physical address. This creates a subnetting effect. Whenever looking for the IP address of 
one of these hosts, the router sends an ARP reply announcing its own physical address. 

To make address resolution easy, choose both IP and physical addresses the same 
length. Address resolution is difficult for Ethernet-like networks because the physical 
address of the Ethernet interface is 48 bits long and the high-level IP address is 32 bits 
long. In order for the 48-bit physical address to encode a 32-bit IP address, the next 
generation of IP is being designed to allow 48-bit physical (hardware) addresses P to be 
encoded in IP addresses I by the functional relationship of P = f(I). Conceptually, it will 
be necessary to choose a numbering scheme that makes address resolution efficient by 
selecting a function f that maps IP addresses to physical addresses. 

As shown in Figure 2.5, the ARP software package consists of the following five 
components: 
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Figure 2.5 Simplified ARP package. 


The cache table has an array of entries used and updated by ARP messages. It is 
inefficient to use the ARP protocol for each datagram destined for the same host or 
router. The solution is to use the cache table. The cache table is implemented as an 
array of entries. When a host or router receives the corresponding physical address 
for an IP datagram, the address can be saved in the cache table within the next few 
minutes. However, mapping in the cache should not be retained for an unlimited time, 
due to the limited cache space. 

A queue contains packets going to the same destination. The ARP package maintains 
a set of queues to hold the IP packets, while ARP tries to resolve the physical address. 
The output module sends unresolved packets to the corresponding queue. The input 
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module removes a packet from a queue and sends it to the physical access layer for 
transmission. 

e The output module takes an IP packet from the IP layer and sends it to a queue as 
well as the physical access layer. The output module checks the cache table to find an 
entry corresponding to the destination IP address of this packet. If the entry is found 
and the state of the entry is resolved, the packet, along with the destination physical 
address, is passed to the physical access layer (or data link layer) for transmission. If 
the entry is found and the state of the entry is pending, the packet should wait until 
the destination physical address is found. If no entry is found, the module creates 
a queue and enqueues the packet. A new cache entry (‘pending’) is created for the 
destination and the attempt field is set to 1. An ARP request is then broadcast. 

e The input module waits until an ARP request or reply arrives. The input module 
checks the cache table to find an entry corresponding to this packet (request or reply). 

If the entry is found and the state of the entry is ‘pending’, the module updates 
the entry by copying the target physical address in the packet to the physical address 
field of the entry and changing the state to ‘resolved’. The module also sets the value 
of the time-out for the entry and then dequeues the packets from the corresponding 
queue, one by one, and delivers them along with the physical address to the physical 
access layer for transmission. 

If the entry is found and the state is ‘resolved’, the module still updates the entry. 
This is because the target physical address could have been changed. The value of the 
time-out field is also reset. If the entry is not found, the module creates a new entry 
and adds it to the cache table. 

Now the module checks to see if the arrived ARP packet is a request. If it is, the 
input module immediately creates an ARP reply message and sends it to the sender. 
The ARP reply packet is created by changing the value of the operation field from 
request to reply and filling in the target physical address. 

e The cache-control module is responsible for maintaining the cache table. It checks 
the cache table periodically, entry by entry. If the entry is free, it continues to the 
next entry. If the state is ‘pending’, the module increments the value of the attempts 
field by 1. It then checks the value of the attempts field. If this value is greater than 
the maximum number of attempts allowed, the state is changed to ‘free’ and the 
corresponding queue is destroyed. However, if the number of attempts is less than the 
maximum, the input module creates and sends another ARP request. If the state of 
the entry is ‘resolved’, the module decrements the value of the ‘time-out’ field by the 
amount of the time elapsed since the last check. If this value is less than or equal to 
zero, the state is changed to free and the queue is destroyed. 


2.1.3 Reverse Address Resolution Protocol (RARP) 


To create an IP datagram, a host or a router needs to know its own IP address, which 
is independent of the physical address. The RARP is designed to resolve the address 
mapping of a machine in which its physical address is known, but its logical (IP) address 
is unknown. The machine can get its physical address, which is unique locally. It can 
then use the physical address to get the logical IP address using the RARP protocol. In 
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Figure 2.6 RARP dynamic mapping. 


reality, RARP is a protocol of dynamic mapping in which a given physical address is 
associated with a logical IP address, as shown in Figure 2.6. 

To get the IP address, a RARP request is broadcast to all systems on the network. 
Every host or router on the physical network will receive the RARP request packet, but 
the RARP server will only answer it as shown in Figure 2.6(b). The server sends a RARP 
reply packet including the IP address of the requestor. 


2.1.4 Classless Interdomain Routing (CIDR) 


CIDR is the standard that specifies the details of both classless addressing and an asso- 
ciated routing scheme. Accordingly, the name is slightly inaccurate designation because 
CIDR specifies addressing as well as routing. 

The original IPv4 model built on network classes was a useful mechanism for allocating 
identifiers (netid and hostid) when the primary users of the Internet were academic and 
research organisations. But, this mode proved insufficiently flexible and inefficient as 
the Internet grew rapidly to include gateways into corporate enterprises with complex 
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networks. By September 1993, it was clear that the growth in Internet users would require 
an interim solution while the details of IPv6 were being finalised. The resulting proposal 
was submitted as RFC 1519 titled ‘Classless Inter-Domain Routing (CIDR): an Address 
Assignment and Aggregation Strategy.’ CIDR is classless, representing a move away from 
the original IPv4 network class model. CIDR is concerned with interdomain routing rather 
than host identification. CIDR has a strategy for the allocation and use of IPv4 addresses, 
rather than a new proposal. 


2.1.5 IP Version 6 (IPv6, or IPng) 


The evolution of TCP/IP technology has led on to attempts to solve problems that improve 
service and extend functionalities. Most researchers seek new ways to develop and extend 
the improved technology, and millions of users want to solve new networking problems 
and improve the underlying mechanisms. The motivation behind revising the protocols 
arises from changes in underlying technology: first, computer and network hardware 
continues to evolve; second, as programmers invent new ways to use TCP/IP, additional 
protocol support is needed; third, the global Internet has experienced huge growth in size 
and use. This section examines a proposed revision of the Internet protocol which is one 
of the most significant engineering efforts so far. 

The network layer protocol is currently IPv4. IPv4 provides the basic communication 
mechanism of the TCP/IP suite. Although IPv4 is well designed, data communication has 
evolved since the inception of IPv4 in the 1970s. Despite its sound design, IPv4 has some 
deficiencies that make it unsuitable for the fast-growing Internet. The IETF decided to 
assign the new version of IP and to name it IPv6 to distinguish it from the current [Pv4. 
The proposed IPv6 protocol retains many of the features that contributed to the success of 
IPv4. In fact, the designers have characterised IPv6 as being basically the same as IPv4 
with a few modifications: IPv6 still supports connectionless delivery, allows the sender to 
choose the size of a datagram, and requires the sender to specify the maximum number 
of hops a datagram can make before being terminated. In addition, IPv6 also retains most 
of IPv4’s options, including facilities for fragmentation and source routing. 

IP version 6 (IPv6), also known as the Internet Protocol next generation (IPng), is the 
new version of the Internet Protocol, designed to be a full replacement for IPv4. IPv6 
has an 128-bit address space, a revised header format, new options, an allowance for 
extension, support for resource allocation and increased security measures. However, due 
to the huge number of systems on the Internet, the transition from IPv4 to IPv6 cannot 
occur at once. It will take a considerable amount of time before every system in the 
Internet can move from IPv4 to IPv6. RFC 2460 defines the new IPv6 protocol. IPv6 
differs from IPv4 in a number of significant ways: 


e The IP address length in IPv6 is increased from 32 to 128 bits. 

e IPv6 can automatically configure local addresses and locate IP routers to reduce con- 
figuration and setup problems. 

e The IPv6 header format is simplified and some header fields dropped. This new header 
format improves router performance and make it easier to add new header types. 

e Support for authentication, data integrity and data confidentiality are part of the IPv6 
architecture. 
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e Anew concept of flows has been added to IPv6 to enable the sender to request special 
handling of datagrams. 


IPv4 has a two-level address structure (netid and hostid) categorised into five classes (A, 
B, C, D and E). The use of address space is inefficient. For instant, when an organisation 
is granted a class A address, 16 million addresses from the address space are assigned 
for the organisation’s exclusive use. On the other hand, if an organisation is granted a 
class C address, only 256 addresses are assigned to this organisation, which may not be 
enough. Soon there will be no addresses left to assign to any new system that wants to 
be connected to the Internet. 

Although the subnetting and supernetting strategies have alleviated some addressing 
problems, subnetting and supernetting make routing more complicated. The encryption 
and authentication options in IPv6 provide confidentiality and integrity of the packet. 
However, no encryption or authentication is provided by IPv4. 


2.1.5.1 IPv6 Addressing 


In December 1995, the network working group of IETF proposed a longer-term solution 
for specifying and allocating IP addresses. RFC 2373 describes the address space asso- 
ciated with the IPv6. The biggest concern with Internet developers will be the migration 
process from IPv4 to IPv6. 

IPv4 addressing has the following shortcoming: IPv4 was defined when the Inter- 
net was small and consisted of networks of limited size and complexity. It offered two 
layers of address hierarchy (netid and hostid) with three address formats (class A, B 
and C) to accommodate varying network sizes. Both the limited address space and the 
32-bit address size in IPv4 proved to be inadequate for handling the increase in the 
size of the routing table caused by the immense numbers of active hosts and servers. 
IPv6 is designed to improve upon IPv4 in each of these areas. IPv6 allocates 128 bits 
for addresses. Analysis shows that this address space will suffice to incorporate flexible 
hierarchies and to distribute the responsibility for allocation and management of the IP 
address space. 

Like IPv4, IPv6 addresses are represented as string of digits (128 bits or 32 hex digits) 
which are further broken down into eight 16-bit integers separated by colons (:). The 
basic representation takes the form of eight sections, each two bytes in length. 


XX!XX!XXIXX!XXIXX!KXXIXX 
where each xx represents the hexadecimal form of 16 bits of address. IPv6 uses hexadec- 


imal colon notation with abbreviation methods. 


Example 2.4 An IPv6 address consists of 16 bytes (octets) which is 128 bits long. 
The IPv6 address consists of 32 hexadecimal digits, with every four digits separated by 
a colon. 
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IPv6 address: flea: 1075:fffb: 1 10e:0000:0000:7c2d:a65f 
Abbreviated address: flea:1075:fffb:110e::7c2d:a65f 
Binary address: 1111000111101010 ... 1010011001011111 


Many of the digits in IPv6 addresses are zeros. In this case, the abbreviated address can be 
obtained by omitting the leading zeros of a section (four hex digits between two colons), 
but not the trailing zeros. 


Example 2.5 Assume that the IPv6 address is given as 
fedc:ab98:0052:43 10:000f:bccf:0000:ff1f (unabbreviated) 


Using the abbreviated form, 0052 can be written as 52, OOOf as f, and 0000 as 0. But the 
trailing zeros cannot be dropped, so that 4310 would not be abbreviated. Thus, the given 
IP address becomes fedc:ab98:52:4310:f:becf:0:fflf (abbreviated). 


Example 2.6 Consider an abbreviated address with consecutive zeros. When consecu- 
tive sections are composed of zeros, further abbreviations are possible. We can remove 
the zeros altogether and replace them with a double semicolon. 


fedc:0:0:0:0:abf8:0:f75f (abbreviated) 
fedc::abf8:0:f75f (more abbreviated) 


IPv6 Address Types 
IPv6 has identified three types of addresses: 


e Unicast: To associate with a specific physical interface to a network. Packets sent to 
a unicast address are delivered to the interface uniquely specified by the address. 

e Anycast: To associate with a set of physical interfaces, generally on different modes. 
Packets sent to an anycast address will be delivered to at least one interface specified 
by the address. 

e Multicast: To associate with a set of physical interfaces, generally on multiple hosts 
(nodes). Packets sent to a multicast address will be delivered to all the interfaces to 
which the address refers. 


Figure 2.7 illustrates three address types. 

IPv6 addresses divide the address space into two parts with the type prefix for each 
type of address, rest of address, and the fraction of each type of address relative to the 
whole address space. Table 2.5 illustrates the address space assignment for type prefixes. 
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Figure 2.7 IPv6 address types. 


2.1.5.2 IPv6 Packet Format 


The IPv6 protocol consists of two parts: the basic elements of the IPv6 header and IPv6 
extension headers. The IPv6 datagram is composed of a base header (40 bytes) followed 
by the payload. The payload consists of two parts: optional extension headers and data 
from the upper layer. The extension headers and data packet from the upper layer usually 
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Table 2.5 Type prefixes for IPv6 addresses 


Type prefix Type of address Fraction of 
(binary) address space 
0000 0000 Reserved 1/256 
0000 0001 Reserved 1/256 
0000 001 NSAP (Network Service Access 1/128 
Point) 
0000 010 IPX (Novell) 1/128 
0000 011 Reserved 1/128 
0000 100 Reserved 1/128 
0000 101 Reserved 1/128 
0000 110 Reserved 1/128 
0000 111 Reserved 1/128 
0001 Reserved 1/16 
001 Reserved 1/8 
010 Provider-based unicast addresses 1/8 
011 Reserved 1/8 
100 Geographic unicast addresses 1/8 
101 Reserved 1/8 
110 Reserved 1/8 
1110 Reserved 1/16 
1111 0 Reserved 1/32 
1111 10 Reserved 1/64 
1111 110 Reserved 1/128 
1111 1110 0 Reserved 1/512 
1111 1110 10 Link local addresses 1/1024 
1111 1110 11 Site local addresses 1/1024 
1111 1111 Multicast addresses 1/256 
Prefix (variable) = Rest of address (variable) 





128 bits 





occupy up to 65535 bytes of information. Figure 2.8 shows the base header with its eight 
fields. Each IPv6 datagram begins with a base header. The IPv6 header has a fixed length 
of 40 octets, consisting of the following fields: 


e Version: This four-bit field defines the version number of the IP. For IPv6, the 
value is 6. 

e Priority: This four-bit priority field defines the priority of the packet with respect to 
traffic congestion. So, this field is a measure of the importance of a datagram. The 
IPv4 service class field has been renamed the IPv6 traffic class field. 

e Flow label: This 24-bit field is designed to provide special handling for a particular 
flow of data. This field contains information that routers use to associate a datagram 
with a specific flow and priority. 
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Figure 2.8 IPv6 base header with its eight fields. 


e Payload length: This 16-bit payload length field defines the total length of the IP 
datagram excluding the base header. A payload consists of optional extension headers 


plus data from the upper layer. It occupies up to 2!® — 1 = 65535 bytes. 


e Next header: The next header is an eight-bit field defining the header that follows the 
base header in the datagram. The next header is either one of the optional extension 
headers used by IP or a header for an upper-layer protocol such as UDP or TCP. 


Extension headers add functionality to the IPv6 datagram. 


Table 2.6 shows the values of next headers (i.e. IPv6 extension headers). 


Six types of extension header have been defined. These are the hop-by-hop option, 
source routing, fragmentation, authentication, encrypted security payload, and destina- 
tion option. These are discussed below. 


Hop-by-hop option: This option is used when the source needs to pass information to all 
routers (in the path) visited by the datagram. 


Table 2.6 Next header codes 


Code 


Next header 


Hop-by-hop option 

ICMP 

TCP 

UDP 

Source routing 
Fragmentation 

Encrypted security payload 
Authentication 

Null (no next header) 
Destination option 
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Source routing: The source routing extension header combines the concepts of the strict 
source route and the loose source route options of IPv4. The source routing extension is 
used when the source wants to specify the transmission path. 

The source routing header contains a minimum of seven fields which are expressed in 
a unified form as follows: 


— The next header and header length are identical to that of hop-by-hop extension header. 
— The type field defines loose or strict routing. 

— The address left field indicates the number of hops still needed to reach the destination. 
— The strict/loose mask field determines the rigidity of routing. 

— The destination address in source routing changes from router to router. 


The fragmentation extension is used if the payload is a fragment of a message. The 
concept of fragmentation is the same as that in IPv4 except that where fragmentation 
takes place differs. In IPv4, the source or router is required to fragment if the size of 
the datagram is larger than the MTU of the network. In IPv6, only the original source 
can fragment using the Path MTU Discovery technique. If the source does not use this 
technique, it should fragment the datagram to a size of 576 bytes or smaller, which is the 
minimum size of MTU required for each network connected to the Internet. 

Encrypted Security Payload (ESP): The ESP is an extension that provides confiden- 
tiality between sender and receiver and guards against eavesdropping. The ESP format 
contains the security parameter index field and the encrypted data field. The security 
parameter index field is a 32-bit word that defines the type of encryption/decryption used. 
The encrypted data field contains the data being encrypted along with any extra param- 
eters needed by the algorithm. Encryption can be implemented in two ways: transport 
mode and tunnel mode, as shown in Figure 2.9. The transport-mode method encrypts 
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Figure 2.9 Encrypted security payload. 
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a TCP segment or UDP user datagram first and then encapsulated along with its base 
header, extension headers and security parameter index (SPI) as shown in Figure 2.9(a). 
The tunnel-mode method encrypts the entire IP datagram together with its base header and 
extension headers and then encapsulates it in a new IP packet as shown in Figure 2.9(b). 

The authentication extension validates the sender of the message and protects the data 
from hackers. The authentication extension field has a dual purpose: sender identification 
and data integrity. The sender verification is needed because the receiver can be sure that 
a message is from the genuine sender and not from an imposter. The data integrity is 
needed to check that the data is not altered in transition by some hackers. The format 
of authentication extension header consists of the security parameter index field and the 
authentication data field. The former defines the algorithm used for authentication, and 
the latter contains the actual data generated by the algorithm. 

The destination extension passes information from the source to the destination exclu- 
sively. This header contains optional information to be examined by the destination mode. 
It is worth comparing the options in IPv4 with the extension headers in IPv6. 


The record route option in IPv4 is not used in IPv6. 

The timestamp option in IPv4 is not implemented in IPv6. 

The source router option in IPv4 is called the source route extension header in IPv6. 
The fragmentation fields in the base header section of IPv4 have moved to the frag- 
mentation extension header in IPv6. 

5. The encrypted security payload extension header is new in IPv6. 


pha a 


e Hop limit: This eight-bit hop limit field decrements by | each node that forwards 
the packet. The packet is discarded if the hop limit is decremented to zero. This 
field serves the same purpose as the TTL field in IPv4. IPv6 interprets the value as 
giving a strict bound on the maximum number of hops a datagram can make before 
being discarded. 

e Source address: The source address field is a 128-bit originator address that identifies 
the initial sender of the packet. 

e Destination address: The destination address field specifies a 128-bit recipient address 
that usually identifies the final destination of the datagram. However, if source routing 
is used, this field contains the address of the next router. 


To summarise, each IPv6 datagram begins with a 40-octet base header that includes 
fields for the source and destination addresses, the maximum hop limit, the traffic class 
(priority), the flow label and the type of the next header. Thus, an IPv6 datagram should 
contain at least 40 octets in addition to the data. 


2.1.5.3. Comparison between IPv4 and IPv6 Headers 


Despite many conceptual similarities, IPv6 changes most of the protocol scopes. Most 
important, IPv6 completely revises the datagram format by replacing IPv4’s variable- 
length options field with a series of fixed-format headers. A comparison between IPv4 
and IPv6 headers will be examined in the following section. 
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e The header length field is eliminated in IPv6 because the length of the header is fixed 
in IPv6. 

e The service type field is eliminated in IPv6. The priority and flow label fields together 
take over the function of the service type field in IPv4. 

e The total length field is eliminated in IPv6 and replaced by the payload length field. 

e The identification, flag and offset fields in IPv4 are eliminated from the base header 
in IPv6. They are included in the fragmentation extension header. 

e The TTL field in IPv4 is called the hop limit in IPv6. 

e The protocol field is replaced by the next header field. 

e The header checksum field in IPv4 is eliminated because the checksum is provided 
by upper level protocols. It is thereby not needed at this level. 

e The option fields in IPv4 are implemented as extension headers in IPv6. 


The length of the base header is fixed at 40 bytes. However, to give more functionality 
to the IP datagram, the base header can be followed by up to six extension headers. 


2.1.6 Internet Control Message Protocol (ICMP) 


The ICMP is an extension to the Internet Protocol which is used to communicate between 
a gateway and a source host, to manage errors and generate control messages. 

The Internet Protocol (IP) is not designed to be absolutely reliable. The purpose of 
control messages (ICMP) is to provide feedback about problems in the communication 
environment, not to make IP reliable. 

There are still no guarantees that a datagram will be delivered or a control message 
will be returned. Some datagrams may still be undelivered without any report of their 
loss. The higher-level protocols that use TCP/IP must implement their own reliability 
procedures if reliable communication is required. 

IP is an unreliable protocol that has no mechanisms for error checking or error control. 
ICMP was designed to compensate for this IP deficiency. However, ICMP does not correct 
errors, simply reports them. ICMP uses the source IP address to send the error message to 
the source of the datagram. ICMP messages consist of error-reporting messages and query 
messages. The error-reporting messages report problems that a router or a destination host 
may encounter when it processes an IP packet. In addition to error reporting, ICMP can 
diagnose some network problems through the query messages. The query messages (in 
pairs) give a host or a network manager specific information from a router or another host. 


2.1.7 Internet Group Management Protocol (IGMP) 


The Internet Group Management Protocol (IGMP) is used to facilitate the simultaneous 
transmission of a message to a group of recipients. IGMP helps multicast routers to 
maintain a list of multicast addresses of groups. ‘Multicasting’ means sending of the 
same message to more than one receiver simultaneously. When the router receives a 
message with a destination address that matches one on the list, it forwards the message, 
converting the IP multicast address to a physical multicast address. To participate in IP 
on a local network, the host must inform local multicast routers. The local routers contact 
other multicast routers, passing on the membership information and establishing route. 
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IGMP has only two types of messages: report and query. The report message is sent 
from the host to the router. The query message is sent from the router to the host. A router 
sends in an IGMP query to determine if a host wishes to continue membership in a group. 
The query message is multicast using the multicast address 244.0.0.1. The report message 
is multicast using a destination address equal to the multicast address being reported. IP 
addresses that start with 1110) are multicast addresses. Multicast addresses are class 
D addresses. 

The IGMP message is encapsulated in an IP datagram with the protocol value of two. 
When the message is encapsulated in the IP datagram, the value of TTL must be one. 
This is required because the domain of IGMP is the LAN. 

The multicast backbone (MBONE) is a set of routers on the Internet that supports 
multicasting. MBONE is based on the multicasting capability of IP. Today MBONE uses 
the services of UDP at the transport layer. 


2.2 Transport Layer Protocols 


Two protocols exist for the transport layer: TCP and UDP. Both TCP and UDP lie between 
the application layer and the network layer. As a network layer protocol, IP is responsible 
for host-to-host communication at the computer level, whereas TCP or UDP is responsible 
for process-to-process communication at the transport layer. 


2.2.1 Transmission Control Protocol (TCP) 


This section describes the services provided by TCP for the application layer. TCP pro- 
vides a connection-oriented byte stream service, which means two end points (normally 
a client and a server) communicating with each other on a TCP connection. TCP is 
responsible for flow/error controls and delivering the error-free datagram to the receiving 
application program. 

TCP needs two identifiers, IP address and port number, for a client/server to make a 
connection offering a full-duplex service. To use the services of TCP, the client socket 
address and server socket address are needed for the client/server application programs. 

The sending TCP accepts a datagram from the sending application program, creates seg- 
ments (or packets) extracted from the datagram, and sends them across the network. The 
receiving TCP receives packets, extracts data from them, orders them if they arrived out of 
order, and delivers them as a byte stream (datagram) to the receiving application program. 


TCP header 


TCP data is encapsulated in an IP datagram as shown in Figure 2.10. The TCP packet (or 
segment) consists of a 20—60-byte header, followed by data from the application program. 
The header is 20 bytes if there is no option and up to 60 bytes if it contains some options. 
Figure 2.11 illustrates the TCP packet format, whose header is explained in the following. 


e Source and destination port numbers (16 bits each): Each TCP segment contains a 
16-bit field each that defines the source and destination port number to identify the 
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Figure 2.10 Encapsulation of TCP data in an IP datagram. 
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Figure 2.11 TCP packet format. 


sending and receiving application. These two port numbers, along with the source 
and destination IP addresses in the IP header, uniquely identify each connection. The 
combination of an IP address and a port number is sometimes called a socket. The 
socket pair, consisting of the client IP address and port number and the server IP 
address and port number, specifies two end points that uniquely identify each TCP 
connection in the Internet. 


Sequence number (32 bits): This 32-bit sequence field defines the sequence number 
assigned to the first byte of data stream contained in this segment. To ensure connec- 
tivity, each byte to be transmitted is numbered. This sequence number identifies the 
byte in the data stream from the sending TCP to the receiving TCP. Considering the 
stream of bytes following in one direction between two applications, TCP will number 
each byte with a sequence number. During connection establishment, each party uses 
a random number generator to create an initial sequence number (ISN) that is usually 
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different in each direction. The 32-bit sequence number is an unsigned number that 
wraps back around to 0 after reaching 2°? — 1. 


Acknowledgement number (32 bits): This 32-bit field defines the byte number that the 
sender of the segment is expecting to receive from the receiver. Since TCP provides a 
full-duplex service to the application layer, data can flow in each direction, independent 
of the other direction. The sequence number refers to the stream flowing in the same 
direction as the segment, while the acknowledgement number refers to the stream 
flowing in the opposite direction from the segment. Therefore, the acknowledgement 
number is the sequence number plus | of the last successfully received byte of data. 
This field is only valid if the ACK flag is on. 


Header length (4 bits): This field indicates the number of four-byte words in the TCP 
header. Since the header length is between 20 to 60 bytes, an integer value of this 
field can be between 5 and 15, because 5 x 4 = 20 bytes and 15 x 4 = 60 bytes. 


Reserved (6 bits): This is a six-bit field reserved for future use. 


Code bits (6 bits): There are six flag bits (or control bits) in the TCP header. One or 
more can be turned on at the same time. Below is a brief description of each flag to 
determine the purpose and contents of the segment. 


URG The urgent point field is valid. 
ACK The acknowledgement number is valid. 


PSH This segment requests a push. 

RST Reset the connection. 

SYN Synchronise sequence number to 
initiate a connection. 

FIN The sender is finished sending data. 


Window size (16 bits): This 16-bit field defines the size of window in bytes. Since the 
window size of this field is 16 bits, the maximum size of the window is 2! — 1 = 
65 535 bytes. TCP’s flow control is provided by each end, advertising a window size. 
This is the number of bytes, starting with the one specified by the acknowledgement 
number field, that the receiver is willing to accept. 


Checksum (16 bits): This 16-bit field contains the checksum. The checksum covers 
the TCP segment, TCP header and TCP data. This is a mandatory field that must be 
calculated and stored by the sender, and then verified by the receiver. 


Urgent pointer (16 bits): This 16-bit field is valid only if the URG flag is set. The 
urgent point is used when the segment contains urgent data. It defines the number that 
must be added to the sequence number to obtain the number of the last urgent byte 
in the data section of the segment. 


Options (24 bits): The options field (if any) varies in length, depending on which 
options have been included. The size of the TCP header varies depending on the 
options selected. The TCP header can have up to 40 bytes of optional information. 
The options are used to convey additional information to the destination or to align 
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other options. The options are classified into two categories: one-byte options contain 
end of option and no operation; multiple-byte operations contain maximum segment 
size, window scale factor and timestamp. 


TCP is a connection-oriented byte stream transport layer protocol in the TCP/IP suite. TCP 
provides a full duplex connection between two applications, allowing them to exchange 
large volumes of data efficiently. Since TCP provides flow control, it allows systems of 
widely varying speeds to communicate. To accomplish flow control, TCP uses a sliding 
window protocol so that it can make efficient use of the network. Error detection is 
handled by the checksum, acknowledgement and timeout. TCP is used by many popular 
applications such as HTTP (World Wide Web), TELNET, Rlogin, FTP and SMTP for 
e-mail. 


2.2.2 User Datagram Protocol (UDP) 


UDP lies between the application layer and IP layer. Like TCP, UDP serves as the interme- 
diary between the application programs and network operations. UDP uses port numbers 
to accomplish a process-to-process communication. The UDP provides a flow-and-control 
mechanism at the transport level. In fact, it performs very limited error checking. UDP 
can only receive a data unit from the process, and deliver it to the receiver unreliably. 
The data unit must be small enough to fit in a UDP packet. If a process wants to send 
a small message and does not care much about reliability, it will use UDP. UDP is a 
connectionless protocol. It is often used for broadcast-type protocols, such as audio or 
video traffic. It is quicker and uses less bandwidth because a UDP connection is not 
continuously maintained. This protocol does not guarantee delivery of information, nor 
does it repeat a corrupted transfer, as does TCP. 


UDP header 


UDP receives the data and adds the UDP header. UDP then passes the user datagram to 
the IP with the socket addresses. IP adds its own header. The IP datagram is then passed 
to the data link layer. The data link layer receives the IP datagram, adds its own header 
and a trailer (possibly), and passes it to the physical layer. The physical layer encodes bits 
into electrical or optical signals and sends it to the remote machine. Figure 2.12 shows 
the encapsulation of a UDP datagram as an IP datagram. The IP datagram contains its 
total length in bytes, so the length of the UDP datagram is this total length minus the 
length of the IP header. 
The UDP header is shown by the fields illustrated in Figure 2.13. 


e Source port numbers (16 bits): This 16-bit port number identifies the sending process 
running on the source host. Since the source port number is 16 bits long, it can range 
from 0 to 65 656 bytes. If the source host is the client, the client program is assigned 
a random port number called the ephemeral port number requested by the process 
and chosen by the UDP software running on the source host. If the source host is the 
server, the port number is a universal port number. 
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Figure 2.12 UDP encapsulation. 
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Figure 2.13. UDP header. 


Destination port numbers (16 bits): This is the 16-bit port number used by the process 
running on the destination host. If the destination host is the server, the port number 
is a universal port number, while if the destination host is the client, the port number 
is an ephemeral port number. 


Length (16 bits): This is a 16-bit field that contains a count of bytes in the UDP 
datagram, including the UDP header and the user data. This 16-bit field can define 
a total length of 0 to 65535 bytes. However, the minimum value for length is eight, 
which indicates an UDP datagram with only header and no data. Therefore, the length 
of data can be between 0 to 65 507 bytes, subtracting the total length 65 535 bytes from 
20 bytes for an IP header and 8 bytes for an UDP header. The length field in a UDP 
user datagram is redundant. The IP datagram contains its total length in bytes, so the 
length of the UDP datagram is this total length minus the length of the IP header. 


Checksum (16 bits): The UDP checksum is used to detect errors over the entire user 
datagram covering the UDP header and the UDP data. UDP checksum calculations 
include a pseudoheader, the UDP header and the data coming from the application 
layer. The value of the protocol field for UDP is 17. If this value changes during 
transmission, the checksum calculation at the receiver will detect it and UDP drops 
the packet. 


The checksum computation at the sender is as follows: 


Add the pseudoheader to the UDP datagram. 
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Fill the checksum field with zero. 

Divide the total bits into 16-bit words. 

If the total number of bytes is not even, add padding of all Os. 
Complement the 16-bit result and insert it in the checksum field. 
Drop the pseudoheader and any added padding. 

Deliver the UDP datagram to the IP software for encapsulation. 


PLOY Ee 


The checksum computation at the receiver is as follows: 


Add the pseudoheader to the UDP datagram. 

Add padding if needed. 

Divide the total bits into 16-bit words. 

Add all 16-bit sections using arithmetic. 

Complement the result. 

If the result is all Os, drop the pseudoheader and any added padding and accept the 
user datagram. Otherwise, discard the user datagram. 


Oe Sue 


Multiplexing and demultiplexing 


In a host running a TCP/IP suite, there is only one UDP but there may be several 
processes that may want to use the services of UDP. To handle this situation, UDP needs 
multiplexing and demultiplexing. 


e Multiplexing: At the sender side, it may have several processes that need user data- 
grams. But there is only one UDP. This is a many-to-one relationship and requires 
multiplexing. UDP accepts messages from different processes, differentiated by their 
assigned port numbers. After adding the header, UDP passes the user datagram to IP. 


e Demultiplexing: At the receiver side, there is only one UDP. However, it may happen 
to be many processes that can receive user datagrams. This is a one-to-many rela- 
tionship and requires demultiplexing. UDP receives user datagrams from IP. After 
error checking and dropping of header, UDP delivers each message to the appropriate 
process based on the port numbers. 


UDP is suitable for a process that requires simple request-response communication 
with little concern for flow and error control. It is not suitable for a process that needs 
to send bulk data, like FTP. However, UDP can be used for a process with internal flow 
and error control mechanisms such as the Trivial File Transfer Protocol (TFTP) process. 
UDP is also used for management processes such as SNMP. 


2.3 World Wide Web 


The World Wide Web (WWW) is a repository of information spread all over the world 
and linked together. The WWW is a distributed client-server service, in which a client 
using a browser can access a service using a server. The Web consists of Web pages that 
are accessible over the Internet. 


48 INTERNET SECURITY 


The Web allows users to view documents that contain text and graphics. The Web grew 
to be the largest source of Internet traffic since 1994 and continues to dominate, with a 
much higher growth rate than the rest of the internet. By 1995, Web traffic overtook FTP 
to become the leader. By 2001, Web traffic completely overshadowed other applications. 


2.3.1 Hypertext Transfer Protocol (HTTP) 


The protocol used to transfer a Web page between a browser and a Web server is known 
as Hypertext Transfer Protocol (HTTP). HTTP operates at the application level. HTTP is 
a protocol used mainly to access data on the World Wide Web. HTTP functions like a 
combination of FTP and SMTP. It is similar to FTP because it transfers files, while HTTP 
is like SMTP because the data transferred between the client and the server looks like 
SMTP messages. However, HTTP differs from SMTP in the way that SMTP messages 
are stored and forwarded; HTTP messages are delivered immediately. 

As a simple example, a browser sends an HTTP GET command to request a Web 
page from a server. A browser contacts a Web server directly to obtain a page. The 
browser begins with a URL, extracts the hostname section, uses DNS to map the name 
into an equivalent IP address, and uses the IP address to form a TCP connection to the 
server. Once the TCP connection is in place, the browser and Web server use HTTP to 
communicate. Thus, if the browser sends a request to retrieve a specific page, the server 
responds by sending a copy of the page. 

A browser requests a Web page, and the server transfers a copy to the browser. HTTP 
also allows transfer from a browser to a server. HTTP allows browsers and servers to 
negotiate details such as the character set to be used during transfers. To improve response 
time, a browser caches a copy of each Web page it retrieves. HTTP allows a machine 
along the path between a browser and a server to act as a proxy server that caches Web 
pages and answers a browser’s request from its cache. Proxy servers are an important 
part of the Web architecture because they reduce the load on servers. 

In summary, a browser and server use HTTP to communicate. HTTP is an application- 
level protocol with explicit support for negotiation, proxy servers, caching and persistent 
connections. 


2.3.2 Hypertext Markup Language (HTML) 


The browser architecture is composed of the controller and the interpreters to display a 
Web document on the screen. The controller can be one of the protocols such as HTTP, 
FTP, Gopher or TELNET. The interpreter can be HTML or Java, depending on the type 
of document. 

The Hypertext Markup Language (HTML) is a language used to create Web pages. A 
markup language such as HTML is embedded in the file itself, and formatting instructions 
are stored with the text. Thus, any browser can read the instructions and format the text 
according to the workstation being used. Suppose a user creates formatted text on a 
Macintosh computer and stores it in a Web page, so another user who is on an IBM 
computer is not able to receive the Web page because the two computers are using 
different formatting procedures. Consider a case where different word processors use 
different techniques or procedures to format text. To overcome these difficulties, HTML 
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uses only ASCII characters for both main text and formatting instructions. Therefore, 
every computer can receive the whole document as an ASCII document. 


Web page 


A Web page consists of two parts: the head and body. The head is the first part of a 
Web page. The head contains the file of the page and other parameters that the browser 
will use. The body contains the actual content of a page. The body includes the text and 
tags (marks). The text is the information contained in a page, whereas the tags define the 
appearance of the document. 


Tags 


Tags are marks that are embedded into the text. Every HTML tag is a name followed by 
an optional list of attributes. An attribute is followed by an equals sign (=) and the value 
of the attribute. Some tags are used alone; some are used in pairs. The tags used in pairs 
are called starting and ending tags. The starting tag can have attributes and values. The 
ending tag cannot have attributes or values, but must have a slash before the name. An 
example of starting and ending tags is shown below: 


< TagName Attribute = Value Attribute = Value... > (Starting tag) 
< Tag Name > (Ending tag) 


A tag is enclosed in two angled brackets like <A> and usually comes in pairs as <A> 
and </A>. The starting tag starts with the name of the tag, and the ending tag starts with 
a backslash followed by the name of the tag. A tag can have a list of attributes, each of 
which can be followed by an equals sign and a value associated with the attribute. 


2.3.3 Common Gateway Interface (CGI) 


A dynamic document is created by a Web server whenever a browser requests the doc- 
ument. When a request arrives, the Web server runs an application program that creates 
the dynamic document. Common Gateway Interface (CGI) is a technology that creates 
and handles dynamic documents. CGI is a set of standards that defines how a dynamic 
document should be written, how the input data should be supplied to the program and 
how the output result should be used. CGI is not a new language, but it allows program- 
mers to use any of several languages such as C, C++, Bourne Shell, Korn Shell or Perl. 
A CGI program in its simplest form is code written in one of the languages supporting 
the CGI. 


2.3.4 Java 


Java is a combination of a high-level programming language, a run-time environment and 
a library that allows a programmer to write an active document and a browser to run it. 
It can also be used as a stand-alone program without using a browser. However, Java is 
mostly used to create a small application program of an applet. 
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2.4 File Transfer 


The file transfer application allows users to send or receive a copy of a data file. Access 
to data on remote files takes two forms: whole-file copying and shared online access. 
FTP is the major file transfer protocol in the TCP/IP suite. TFTP provides a small, simple 
alternative to FTP for applications that need only file transfer. NFS provides online shared 
file access. 


2.4.1. File Transfer Protocol (FTP) 


File Transfer Protocol (FTP) is the standard mechanism provided by TCP/IP for copying 
a file from one host to another. The FTP protocol is defined in RFC959. It is further 
defined in RFC 2227, 2640, 2773 for updated documentation. 

In transferring files from one system to another, two systems may have different ways 
to represent text and data. Two systems may have different directory structures. All of 
these problems have been solved by FTP in a very simple and elegant way. 

FTP differs from other client-server applications in that it establishes two connections 
between the hosts. One connection is used for data transfer (port 20), the other for control 
information (port 21). The control connection port remains open during the entire FTP 
session and is used to send control messages and client commands between the client and 
server. A data connection is established using an ephemeral port. The data connection 
is created each time a file is transferred between the client and server. Separation of 
commands and data transfer makes FTP more efficient. FTP allows the client to specify 
whether a file contains text (ASCII or EBCDIC character sets) or binary integers. FTP 
requires clients to authorise themselves by sending a log name and password to the server 
before requesting file transfers. 

Since FTP is used only to send and receive files, it is very difficult for hackers to 
exploit. 


2.4.2 Trivial File Transfer Protocol (TFTP) 


Trivial File Transfer Protocol (TFTP) is designed to simply copy a file without the need 
for all of the functionalities of the FTP protocol. TFTP is a protocol that quickly copies 
files because it does not require all the sophistication provided in FTP. TFTP can read or 
write a file for the client. Since TFTP restricts operations to simple file transfer and does 
not provide authentication, TFTP software is much smaller than FTP. 


2.4.3 Network File System (NFS) 


The Network File System (NFS), developed by Sun Microsystems, provides online shared 
file access that is transparent and integrated. The file access mechanism accepts the request 
and automatically passes it to either the local file system software or to the NFS client, 
depending on whether the file is on the local disk or on a remote machine. When it 
receives a request, the client software uses the NFS protocol to contact the appropriate 
server on a remote machine and performs the requested operation. When the remote server 
replies, the client software returns the results to the application program. 
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Since Sun’s Remote Procedure Call (RPC) and eXternal Data Representation (XDR) are 
defined separately from NFS, programmers can use them to build distributed applications. 


2.5 Electronic Mail 


In this section, we consider electronic mail service and the protocols that support it. An 
electronic mail (e-mail) facility allows users to send small notes or large voluminous 
memos across the Internet. E-mail is popular because it offers a fast, convenient method 
of transferring information and communicating. 


2.5.1. Simple Mail Transfer Protocol (SMTP) 


The Simple Mail Transfer Protocol (SMTP) provides a basic e-mail facility. SMTP is the 
protocol that transfers e-mail from one server to another. It provides a mechanism for 
transferring messages among separate servers. Features of SMTP include mailing lists, 
return receipts and forwarding. SMTP accepts the incoming message and makes use of 
TCP to send it to an SMTP module on another servers. The target SMTP module will 
make use of a local electronic mail package to store the incoming message in a user’s 
mailbox. Once the SMTP server identifies the IP address for the recipient’s e-mail server, 
it sends the message through standard TCP/IP routing procedures. 

Since SMTP is limited in its ability to queue messages at the receiving end, it’s usually 
used with one of two other protocols, POP3 or IMAP, that let the user save messages 
in a server mailbox and download them periodically from the server. In other words, 
users typically use a program that uses SMTP for sending e-mail and either POP3 or 
IMAP for receiving messages that have been received for them at their local server. Most 
mail programs (such as Eudora) let you specify both an SMTP server and a POP server. 
On UNIX-based systems, sendmail is the most widely-used SMTP server for e-mail. 
Earlier versions of sendmail presented many security risk problems. Through the years, 
however, sendmail has become much more secure, and can now be used with confidence. 
A commercial package, sendmail, includes a POP3 server and there is also a version for 
Windows NT. 

Hackers often use different forms of attack with SMTP. A hacker might create a fake 
e-mail message and send it directly to an SMTP server. Other security risks associated 
with SMTP servers are denial-of-service attacks. Hackers will often flood an SMTP server 
with so many e-mails that the server cannot handle legitimate e-mail traffic. This type 
of flood effectively makes the SMTP server useless, thereby denying service to legiti- 
mate e-mail users. Another well-known risk of SMTP is the sending and receiving of 
viruses and Trojan horses. The information in the header of an e-mail message is easily 
forged. The body of an e-mail message contains standard text or a real message. Newer 
e-mail programs can send messages in HTML format. No viruses and Trojans can be 
contained within the header and body of an e-mail message, but they may be sent as 
attachments. The best defence against malicious attachments is to purchase an SMTP 
server that scans all messages for viruses, or to use a proxy server that scans all incoming 
and outgoing messages. 
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SMTP is usually implemented to operate over TCP port 25. The details of SMTP are 
in RFC 2821 of the Internet Engineering Task Force (IETF). An alternative to SMTP that 
is widely used in Europe is X.400. 


2.5.2 Post Office Protocol Version 3 (POP3) 


The most popular protocol used to transfer e-mail messages from a permanent mailbox 
to a local computer is known as the Post Office Protocol version 3 (POP3). The user 
invokes a POP3 client, which creates a TCP connection to a POP3 server on the mailbox 
computer. The user first sends a login and a password to authenticate the session. Once 
authentication has been accepted, the user client sends commands to retrieve a copy of one 
or more messages and to delete the message from the permanent mailbox. The messages 
are stored and transferred as text files in RFC 2822 standard format. 

Note that computers with a permanent mailbox must run two servers — an SMTP 
server accepts mail sent to a user and adds each incoming message to the user’s permanent 
mailbox, and a POP3 server allows a user to extract messages from the mailbox and delete 
them. To ensure correct operation, the two servers must coordinate with the mailbox so 
that if a message arrives via SMTP while a user extracts messages via POP3, the mailbox 
is left in a valid state. 


2.5.3 Internet Message Access Protocol (IMAP) 


The Internet Message Access Protocol (IMAP) is a standard protocol for accessing e- 
mail from your local server. IMAP4 (the latest version) is a client-server protocol in 
which e-mail is received and held for you by your Internet server. You (or your e-mail 
client) can view just the subject and the sender of the e-mail and then decide whether to 
download the mail. You can also create, manipulate and delete folders or mailboxes on 
the server, delete messages or search for certain e-mails. IMAP requires continual access 
to the server during the time that you are working with your mail. 

A less sophisticated protocol is Post Office Protocol 3 (POP3). With POP3, your mail is 
saved for you in your mailbox on the server. When you read your mail, it is immediately 
downloaded to your computer and no longer maintained on the server. 

IMAP can be thought of as a remote file server. POP can be thought of as a ‘store- 
and-forward’ service. 

POP and IMAP deal with receiving e-mail from your local server and are not to be 
confused with SMTP, a protocol for transferring e-mail between points on the Internet. 
You send e-mail by SMTP and a mail handler receives it on your recipient’s behalf. Then 
the mail is read using POP or IMAP. 


2.5.4 Multipurpose Internet Mail Extension (MIME) 


The Multipurpose Internet Mail Extension (MIME) is defined to allow transmission of 
non-ASCII data via e-mail. MIME allows arbitrary data to be encoded in ASCII and then 
transmitted in a standard e-mail message. SMTP cannot be used for languages that are 
not supported by seven-bit ASCII characters. It cannot also be used for binary files or to 
send video or audio data. 
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MIME is a supplementary protocol that allows non-ASCII data to be sent through 
SMTP. MIME is a set of software functions that transforms non-ASCII data to ASCII 
data and vice versa. 


2.6 Network Management Service 


This section takes a look at a protocol that more directly supports administrative functions. 
RFC 1157 defines the Simple Network Management Protocol (SNMP). 


2.6.1 Simple Network Management Protocol (SNMP) 


The Simple Network Management Protocol (SNMP) is an application-layer protocol that 
facilitates the exchange of management information between network devices. It is part 
of the TCP/IP protocol suite. SNMP enables network administrators to manage network 
performance, find and solve network problems and plan for network growth. 

There are two versions of SNMP, v1 and v2. Both versions have a number of features 
in common, but SNMP v2 offers enhancements, such as additional protocol operations. 

SNMP version | is described in RFC 1157 and functions within the specifications of 
the Structure of Management Information (SMI). SNMP v1 operates over protocols such 
as the User Datagram Protocol (UDP), IP, OSI Connectionless Network Service (CLNS), 
Apple-Talk Datagram-Delivery Protocol (DDP), and Novell Internet Packet Exchange 
(IPX). SNMP v1 is widely used and is the de facto network management protocol in the 
Internet community. 

SNMP is a simple request—response protocol. The network management system issues 
a request, and managed devices return responses. This behaviour is implemented using 
one of four protocol operations: Get, GetNext, Set and Trap. The Get operation is used 
by the network management system (NMS) to retrieve the value of one or more object 
instances from an agent. If the agent responding to the Get operation cannot provide 
values for all the object instances in a list, it provides no values. The GetNext operation 
is used by the NMS to retrieve the value of the next object instance in a table or list 
within an agent. The Set operation is used by the NMS to set the values of object instances 
within an agent. The Trap operation is used by agents to asynchronously inform the NMS 
of a significant event. 

SNMP version 2 is an evolution of the SNMP v1. It was originally published as a set 
of proposed Internet Standards in 1993. SNMP v2 functions within the specifications of 
the Structure of Management Information (SMI) which defines the rules for describing 
management information, using Abstract Syntax Notation One (ASN.1). The Get, GetNext 
and Set operation used in SNMP vl are exactly the same as those used in SNMP v2. 
However, SNMP v2 adds and enhances some protocol operations. SNMP v2 also defines 
two new protocol operations: GetBulk and Inform. The GetBulk operation is used by 
the NMS to efficiently retrieve large blocks of data, such as multiple rows in a table. 
GetBulk fills a response message with as much of the requested data as will fit. The 
Inform operation allows one NMS to send trap information to another NMS and receive 
a response. 
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SNMP lacks any authentication capabilities, which results in vulnerability to a variety 
of security threats. These include masquerading, modification of information, message 
sequence and timing modifications and disclosure. 


2.7 Converting IP Addresses 


To identify an entity, TCP/IP protocols use the IP address, which uniquely identifies the 
connection of a host to the Internet. However, users prefer a system that can map a name 
to an address or an address to a name. This section considers converting a name to an 
address and vice versa, mapping between high-level machine names and IP addresses. 


2.7.1 Domain Name System (DNS) 


The Domain Name System (DNS) uses a hierarchical naming scheme known as domain 
names. The mechanism that implements a machine name hierarchy for TCP/IP is called 
DNS. DNS has two conceptual aspects: the first specifies the name syntax and rules 
for delegating authority over names, and the second specifies the implementation of a 
distributed computing system that efficiently maps names to addresses. 

DNS is a protocol that can be used in different platforms. In the Internet, the domain 
name space is divided into three different sections: generic domain, country domain and 
inverse domain. A DNS server maintains a list of hostnames and IP addresses, allowing 
computers that query them to find remote computers by specifying hostnames rather than 
IP addresses. DNS is a distributed database and therefore DNS servers can be configured 
to use a sequence of name servers, based on the domains in the name being looked for. 


2.8 Routing Protocols 


An Internet is a combination of networks connected by routers. When a datagram goes 
from a source to a destination, it will probably pass through many routers until it reaches 
the router attached to the destination network. A router chooses the route with the shortest 
metric. The metric assigned to each network depends on the type of protocol. The Routing 
Information Protocol (RIP) is a simple protocol which treats each network as equals. The 
Open Shortest Path First (OSPF) protocol is an interior routing protocol that is becoming 
very popular. Border Gateway Protocol (BGP) is an inter-autonomous system routing 
protocol which first appeared in 1989. 


2.8.1 Routing Information Protocol (RIP) 


The Routing Information Protocol (RIP) is a protocol used to propagate routing informa- 
tion inside an autonomous system. Today, the Internet is so large that one routing protocol 
cannot handle the task of updating the routing tables of all routers. 

Therefore, the Internet is divided into autonomous systems. An Autonomous System 
(AS) is a group of networks and routers under the authority of a single administration. 
Routing inside an autonomous system is referred to as interior routing. RIP and OSPF are 
popular interior routing protocols used to update routing tables in an AS. Routing between 
autonomous systems is referred to as exterior routing. RIP is a popular protocol which 
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belongs to the interior routing protocol. It is a very simple protocol based on distance 
vector routing, which uses the Bellman—Ford algorithm for calculating routing tables. A 
RIP routing table entry consists of a destination network address, the hop count to that 
destination and the IP address of the next router. RIP uses three timers: the periodic timer 
controls the advertising of the update message, the expiration timer governs the validity 
of a route, and the garbage collection timer advertises the failure of a route. However, 
two shortcomings associated with the RIP protocol are slow convergence and instability. 


2.8.2 Open Shortest Path First (OSPF) 


The Open Shortest Path First (OSPF) is a new alternative to RIP as an interior routing 
protocol. It overcomes all the limitations of RIP. Link-state routing is a process by which 
each router shares its knowledge about its neighbourhood with every other router in the 
area. OSPF uses link-state routing to update the routing tables in an area, as opposed to 
RIP which is a distance-vector protocol. The term distance-vector means that messages 
sent by RIP contain a vector of distances (hop counts). In reality, the important difference 
between two protocols is that a link-state protocol always converges faster than a distance- 
vector protocol. 

OSPF divides an autonomous system (AS) in areas, defined as collections of networks, 
hosts and routers. At the border of an area, area border routers summarise information 
about the area and send it to other areas. There is a special area called the backbone among 
the areas inside an autonomous system. All the areas inside an AS must be connected to 
the backbone whose area identification is zero. OSPF defines four types of links: point- 
to-point, transient, stub and virtual. Point-to-point links between routers do not need an IP 
address at each end. Unnumbered links can save IP addresses. A transient link is a network 
with several routers attached to it. A stub link is a network that is connected to only one 
router. When the link between two routers is broken, the administration may create a 
virtual link between them using a longer path that probably goes through several routers. 

A simple authentication scheme can be used in OSPF. OSPF uses multicasting rather 
than broadcasting in order to reduce the load on systems not participating in OSPF. 
Distance-vector Multicast Routing Protocol (DVMRP) is used in conjunction with IGMP 
to handle multicast routing. DVMRP is a simple protocol based on distance-vector routing 
and the idea of MBONE. Multicast Open Shortest Path First (MOSPF), an extension to 
the OSPF protocol, adds a new type of packet (called the group membership packet) to the 
list of link state advertisement packets. MOSPF also uses the configuration of MBONE 
and islands. 


2.8.3 Border Gateway Protocol (BGP) 


BGP is an exterior gateway protocol for communication between routers in different 
autonomous systems. BGP is based on a routing method called path-vector routing. Refer 
to RFC 1772 (1991) which describes the use of BGP in the Internet. BGP version 3 is 
defined in RFC 1267 (1991) and BGP version 4 in RFC 1467 (1993). 

Path-vector routing is different from both distance-vector routing and link-state routing. 
Path-vector routing does not have the instability nor looping problems of distance-vector 
routing. Each entry in the routing table contains the destination network, the next router 
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and the path to reach the destination. The path is usually defined as an ordered list of 
autonomous systems that a packet should travel through to reach the destination. 

BGP is different from RIP and OSPF in that BGP uses TCP as its transport protocol. 
There are four types of BGP messages: open, update, keepalive and notification. BGP 
detects the failure of either the link or the host on the other end of the TCP connection 
by sending a keepalive message to its neighbour on a regular basis. 


2.9 Remote System Programs 


High-level services allow users and programs to interact with automated services on 
remote machines and with remote users. This section describes programs that include 
Rlogin (Remote login) and TELNET (TErminaL NETwork). 


2.9.1 TELNET 


TELNET is a simple remote terminal protocol that allows a user to log on to a computer 
across an Internet. TELNET establishes a TCP connection, and then passes keystrokes 
from the user’s keyboard directly to the remote computer as if they had been typed on a 
keyboard attached to the remote machine. TELNET also carries output from the remote 
machine back to the user’s screen. The service is called transparent because it looks as 
if the user’s keyboard and display attach directly to the remote machine. TELNET client 
software allows the user to specify a remote machine either by giving its domain name 
or IP address. 

TELNET offers three basic services. First, it defines a network virtual terminal that 
provides a standard interface to remote systems. Second, TELNET includes a mechanism 
that allows the client and server to negotiate options. Finally, TELNET treats both ends 
of the connection symmetrically. 


2.9.2 Remote Login (Rlogin) 


Rlogin was designed for remote login only between UNIX hosts. This makes it a simpler 
protocol than TELNET because option negotiation is not required when the operating 
system on the client and server are known in advance. Over the past few years, Rlogin has 
also ported to several non-UNIX environments. RFC 1282 specifies the Rlogin protocol. 

When a user wants to access an application program or utility located on a remote 
machine, the user performs remote login. The user sends the keystrokes to the terminal 
driver where the local operating system accepts the characters but does not interpret 
them. The characters are sent to the TELNET client, which transforms the characters into 
a universal character set called Network Virtual Terminal (NVT) characters and delivers 
them to the local TCP/IP stack. 

The commands or text (in NVT form) travel through the Internet and arrive at the 
TCP/IP stack at the remote machine. Here the characters are delivered to the operating 
system and passed to the TELNET server, which changes the characters to the corre- 
sponding characters understandable by the remote computer. 
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Symmetric Block Ciphers 


This chapter deals with some important block ciphers that have been developed in the 
past. They are IDEA (1992), RCS (1995), RC6 (1996), DES (1977) and AES (2001). The 
Advanced Encryption Standard (AES) specifies a FIPS-approved symmetric block cipher 
which will soon come to be used in lieu of Triple DES or RC6. 


3.1 Data Encryption Standard (DES) 


In the late 1960s, IBM initiated a Lucifer research project, led by Horst Feistel, for 
computer cryptography. This project ended in 1971 and LUCIFER was first known as a 
block cipher that operated on blocks of 64 bits, using a key size of 128 bits. Soon after 
this IBM embarked on another effort to develop a commercial encryption scheme, which 
was later called DES. This research effort was led by Walter Tuchman. The outcome of 
this effort was a refined version of Lucifer that was more resistant to cryptanalysis. 

In 1973, the National Bureau of Standards (NBS), now the National Institute of 
Standards and Technology (NIST), issued a public request for proposals for a national 
cipher standard. IBM submitted the research results of the DES project as a possible 
candidate. The NBS requested the National Security Agency (NSA) to evaluate the algo- 
rithm’s security and to determine its suitability as a federal standard. In November 1976, 
the Data Encryption Standard was adopted as a federal standard and authorised for use on 
all unclassified US government communications. The official description of the standard, 
FIPS PUB 46, Data Encryption Standard was published on 15 January 1977. The DES 
algorithm was the best one proposed and was adopted in 1977 as the Data Encryption 
Standard even though there was much criticism of its key length (which had changed from 
Lucifer’s original 128 bits to 64 bits) and the design criteria for the internal structure of 
DES, i.e., S-box. Nevertheless, DES has survived remarkably well over 20 years of intense 
cryptanalysis and has been a worldwide standard for over 18 years. The recent work on 
differential cryptanalysis seems to indicate that DES has a very strong internal structure. 
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Since the terms of the standard stipulate that it be reviewed every five years, on 
6 March 1987 the NBS published in the Federal Register a request for comments on the 
second five-year review. The comment period closed on 10 December 1992. After much 
debate, DES was reaffirmed as a US government standard until 1992 because there was 
still no alternative for DES. The NIST again solicited a review to assess the continued 
adequacy of DES to protect computer data. In 1993, NIST formally solicited comments 
on the recertification of DES. After reviewing many comments and technical inputs, NIST 
recommend that the useful lifetime of DES would end in the late 1990s. In 2001, the 
Advanced Encryption Standard (AES), known as the Rijndael algorithm, became an FIPS- 
approved advanced symmetric cipher algorithm. AES will be a strong advanced algorithm 
in lieu of DES. 

The DES is now a basic security device employed by worldwide organisations. There- 
fore, it is likely that DES will continue to provide network communications, stored data, 
passwords and access control systems. 


3.1.1 Description of the Algorithm 


DES is the most notable example of a conventional cryptosystem. Since it has been well 
documented for over 20 years, it will not be discussed in detail here. 

DES is a symmetric block cipher, operating on 64-bit blocks using a 56-bit key. DES 
encrypts data in blocks of 64 bits. The input to the algorithm is a 64-bit block of plaintext 
and the output from the algorithm is a 64-bit block of ciphertext after 16 rounds of 
identical operations. The key length is 56 bits by stripping off the 8 parity bits, ignoring 
every eighth bit from the given 64-bit key. 

As with any block encryption scheme, there are two inputs to the encryption function: 
the 64-bit plaintext to be encrypted and the 56-bit key. The basic building block of DES is 
a suitable combination of permutation and substitution on the plaintext block (16 times). 
Substitution is accomplished via table lookups in S-boxes. Both encryption and decryption 
use the same algorithm except for processing the key schedule in the reverse order. 

The plaintext block X is first transposed under the initial permutation IP, giving 
Xo = IP(X) = (Lo, Ro). After passing through 16 rounds of permutation, XORs and sub- 
stitutions, it is transposed under the inverse permutation IP~! to generate the ciphertext 
block Y. If X; = (L;, R;) denotes the result of the ith round encryption, then we have 


L; = Ri-1 
R; = Li-1 ® f (Ri-1, Ki) 


The ith round encryption of DES algorithm is shown in Figure 3.1. The block diagram 
for computing the f(R, K)-function is shown in Figure 3.2. The decryption process can 
be derived from the encryption terms as follows: 


Ri. = Lj 
Li-1 = Ri ® f (Ri-1, Ki) = Ri ® fF (Li, Ki) 


If the output of the ith round encryption be L;||R;, then the corresponding input to the 
(16-i)th round decryption is R;||L;. The input to the first round decryption is equal to 
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Figure 3.1 The ith round of DES algorithm. 
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Figure 3.2 Computation of the f-function. 
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the 32-bit swap of the output of the 16th round encryption process. The output of the 
first round decryption is Ljs5||Ri5, which is the 32-bit swap of the input to the 16th round 
of encryption. 


3.1.2 Key Schedule 


The 64-bit input key is initially reduced to a 56-bit key by ignoring every eighth bit. This 
is described in Table 3.1. These ignored 8 bits, kg, k16, koa, k32, kao, kag, ks6, koa are used 
as a parity check to ensure that each byte is of old parity and no errors have entered 
the key. 

After the 56-bit key was extracted, they are divided into two 28-bit halves and loaded into 
two working registers. The halves in registers are shifted left either one or two positions, 
depending on the round. The number of bits shifted is given in Table 3.2. 

After being shifted, the halves of 56 bits (C;, D;), 1 < i < 16, are used as the key input 
to the next iteration. These halves are concatenated in the ordered set and serve as input 
to the Permuted Choice 2 (see Table 3.3), which produces a 48-biy key output. Thus, a 
different 48-bit key is generated for each round of DES. These 48-bit keys, K;, Ko, ..., 
Kj, are used for encryption at each round in the order from K,; through Kj6. The key 
schedule for DES is illustrated in Figure 3.3. 

With a key length of 56 bits, these are 2° = 7.2 x 10!° possible keys. Assuming that, on 
average, half the key space has to be searched, a single machine performing one DES 
encryption per j1s would take more than 1000 years to break the cipher. Therefore, a 
brute-force attack on DES appears to be impractical. 


Table 3.1 Permuted choice | (PC-1) 


57 49 41 33 25 17 9 1 58 50 42 34 26 18 
10 2 59 51 43 35 27 19 11 3 60 52 44 36 
63 55 47 39 31 23 15 7 62 54 46 38 30 22 
14 6 61 53 45 37 29 21 13 5 28 20 12 4 


Table 3.2. Schedule for key shifts 


Round 1 2 3 4 5 6 7 8 9 10 11 #12 #13 #14 «15 ~«16 
number 
Number of Pe de 22e-- 82 2 D2 2° De S232) aD De DD 1 
left shifts 


Table 3.3. Permuted choice 2 (PC-2) 


14 17 11 24 1 5 3 28 15 6 21 10 
23 19 12 4 26 8 16 7 27 20 13 2 
41 52 31 37 47 55 30 40 51 45 33 48 
44 49 39 56 34 53 46 42 50 36 29 32 
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Figure 3.3 Key schedule for DES. 
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Example 3.1. Assume that a 64-bit key input is K = 581fbc94d3a452ea, including 8 
parity bits. Find the first three round keys only: K,, K2, and K3. 
The register contents Cp (left) and Dp (right) are computed using Table 3.1: 


Co = bed1a45 
Do = d22e87f 


Using Table 3.2, the blocks C; and D, are obtained from the block Cp and Dp by shifting 
one bit to the left as follows: 


C, = 79a348b 
D, = a45d0ff 


The 48-bit key K, is derived using Table 3.3 (PC-2) by inputting the concatenated block 
(C,||D,) such that K; = 27a169e58dda. 

The concatenated block (C2||D2) is computed from (C;||D,) by shifting one bit to the 
left as shown below: 


(C2||D2) = 1346916 48balff 


Using Table 3.3 (PC-2), the 48-bit key K, at round 2 is computed as Ky = da91ddd7b748. 
Similarly, (C3||D3) is generated from shifting (C2||D2) by two bits to the left as follows: 


(C3||D3) = cdla456 22e87fd 
Using Table 3.3, we have 
Kz = 1dc24bf89768 


In a similar fashion, all the other 16-round keys can be computed and the set of entire 
DES keys is listed as follows: 


K, = 27a169e58dda 
K3 = Idc24bf89768 
Ks = b829c57c7cb8 
K7 = c535b4a7fa32 
Ky = e80d33d75314 
Ky; = 83b69cf0ba8d 
Ki; = f6f0483£39ab 
Kis = 6c591f67a976 


3.1.3. DES Encryption 


DES operates on a 64-bit block of plaintext. After initial permutation, the block is split 
into two blocks L; (left) and R; (right), each 32 bits in length. This permuted plaintext 


K, = da91ddd7b748 
Ky = 2359ae58fe2e 

Ke = 116e39a9787b 
Kg = d68ec5b50f76 

Kio = e5aa2dd123ec 
Kyo = 7clef27236bf 
Ky4 = 0ac756267973 
Kyo = 4£57a0c6c35b 
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Table 3.4 Initial permutation (IP) 


58 50 42 34 26 18 10 2 
L; 60 52 44 36 28 20 12 4 
62 54 46 38 30 22 14 6 
64 56 48 40 32 24 16 8 
57 49 41 33 25 17 9 1 
R; 59 51 43 35 27 19 11 3 
61 53 45 37 29 21 13 5 
63 55 47 39 31 23 15 7 





(see Table 3.4) has bit 58 of the input as its first bit, bit 50 as its second bit, and so 
on down to bit 7 as the last bit. The right half of the data, R;, is expanded to 48 bits 
according to Table 3.5 of an expansion permutation. 

The expansion symbol E of E(R;) denotes a function which takes the 32-bit R; as input 
and produces the 48-bit E(R;) as output. The purpose of this operation is twofold — to 
make the output the same size as the key for the XOR operation, and to provide a longer 
result that is compressed during the S-box substitution operation. 

After the compressed key K; is XORed with the expanded block E(R;_1) such that 

T; = E(Ri_1) @ K; for 1 <i < 15, this 48-bit ; moves to substitution operations that 
are performed by eight S;-boxes. The 48-bit I; is divided into eight 6-bit blocks. Each 
6-bit block is operated on by a separate S;-box, as shown in Figure 3.2. Each S;-box 
is a table of 4 rows and 16 columns as shown in Table 3.6. This 48-bit input IT; to 
the S-boxes are passed through a nonlinear S-box transformation to produce the 32- 
bit output. 
If each S; denotes a matrix box defined in Table 3.6 and A denotes an input block of 6 
bits, then S;(A) is defined as follows: the first and last bits of A represent the row number 
of the matrix S;, while the middle 4 bits of A represent a column number of S; in the 
range from 0 to 15. 

For example, for the input (101110) to Ss-box, denote as sp (0111), the first and last 
bits combine to form 10, which corresponds to the row 2 (actually third row) of S;. The 
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Table 3.6 S-boxes 
1 2 3 4 5 6 7 8 9 10 11 #12 #13 «14 «15 


4 13 1 2 15 Ii 8 3 10 6 12 5 9 0 id 
15 7 4 14 2. 113 1 10 6 12 Ii 9 5 3 8 
1 14 8 13 6 2 11 15 12 9 7 3 10 5 0 
12 8 2 4 9 1 7 5 il 3. 14 10 0 6 13 
1 8 14 6 Il 3 4 9 7 2 13 12 0 5 10 
13 4 7 15 2 8 14 12 0 1 10 6 9 Il 5 
14 7 11 10 4 13 1 5 8 12 6 9 3 2,° 115 
8 10 1 3 15 4 2 Iii 6 7 12 0 5 14 9 
0 9 14 6 3» “Wd 5 1 13 12 7 il 4 2 8 
7 0 9 3 4 6 10 2 8 5 14 12 11 15 1 
6 4 9 8 15 3 0 11 1 2 12 5 10 14 7 
10 13 0 6 9 8 7 4 15 14 3 «11 5 2 12 
13. 14 3 0 6 9 10 1 2 8 5 ll 12 4 15 
8 11 5 6 15 0 3 4 7 2 12 1 10 14 9 
6 9 0 12 #11 7 13 = 15 1 3 «14 5 2 8 4 
15 0 6 10 1 13 8 9 4 5 11 12 7 2 14 
12 4 1 7 #10 Ii 6 8 5 3. 15) 13 0 14 9 
11 24 12 4 T 13 1 5 0 15 10 3 9 8 6 
2 1 11 10 = 13 7 8 15 9 12 5 6 3 O 14 
8 12 7 1 14 2 13 6 15 0 9 10 4 5 3 
1 10 15 9 2 6 8 0 13 3 4 14 7 os 11 
15 4 2 7 12 9 5 6 1 13 14 0 11 3 8 
14 15 5 2 8 12 3 7 0 4 10 1 13 #11 6 
3 2 12 9 5 15 10 11 14 1 7 6 0 8 13 
11 2 14 #15 0 8 13 3. 12 9 7 5 10 6 1 
0 iil 7 4 9 1 10 14 3 5 12 24 15 8 6 
4 11 13 12 3 7 14 10 °= 15 6 8 0 5 9 2 
11 13 8 1 4 10 7 9 3 0 15 14 2 3. 12 
2 8 4 6 15 11 1 10 9 3 «14 5 0 12 7 
15 13 8 10 3 7 4 12 3 6 il O 14 9 2 
11 4 1 9 12 14 2 0 6 10 13° «15 3 5 8 
1 14 7 4 10 8 13 15 12 9 0 3 5 6 ill 





middle 4 bits combine to form 0111, which corresponds to the column 7 (actually the 
eighth column) of the same S5-box. Thus, the entry under row 2, column 7 of Ss-box is 
computed as: 


$}°(0111) = S2(7) = 8 (hexadecimal) = 1000 (binary) 


Thus, the value of 1000 is substituted for 101110. That is, the four-bit output 1000 from 
Ss is substituted for the six-bit input 101110 to Ss. Eight four-bit blocks are the S-box 
output resulting from the substitution phase, which recombine into a single 32-bit block Q; 
by concatenation. This 32-bit output Q; of the S-box substitution are permuted according 
to Table 3.7. This permutation maps each input bit of Q; to an output position of P((;). 
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Table 3.7 Permutation function P 


16 7 20 21 
29 12 28 17 
1 15 23 26 
5 18 31 10 
2 8 24 14 
32 27 3 9 
19 13 30 6 
22 11 4 25 


Table 3.8 Inverse of initial permutation, IP~! 


40 8 48 16 56 24 64 32 
39 7 47 15 55 23 63 31 
38 6 46 14 54 22 62 30 
37 5 45 13 53 21 61 29 
36 4 44 12 52 20 60 28 
35 3 43 11 51 19 59 27 
34 2 42 10 50 18 58 26 
33 1 41 9 49 17 57 25 


The output P(Q2;) are obtained from the input Q; by taking the 16th bit of Q,; as the first 
bit of P(Q2;), the seventh bit as the second bit of P(Q;), and so on until the 25th bit of Q; 
is taken as the 32nd bit of P(Q2;). Finally, the permuted result is XORed with the left half 
L; of the initial permuted 64-bit block. Then the left and right halves are swapped and 
another round begins. The final permutation is the inverse of the initial permutation, and 
is described in Table 3.8 IP~'. Note here that the left and right halves are not swapped 
after the last round of DES. Instead, the concatenated block Rj6||L16 is used as the input 
to the final permutation of Table 3.8 (IP~'). Thus, the overall structure for DES algorithm 
is shown in Figure 3.4. 


Example 3.2 Suppose the 64-bit plaintext is ¥ = 3570e2f1ba4682c7, and the same key 
as used in Example 3.1, K = 581fbc94d3a452ea is assumed again. The first two-round 
keys are, respectively, K; = 27a169e58dda and Ky = da91ddd76748. 

For the purpose of demonstration, the DES encryption aims to limit the first two 
rounds only. The plaintext X splits into two blocks (Lo, Ro) using Table 3.4 IP such that 
Lo = aelbal89 and Ro = delfl0f4. 

The 32-bit Ro is expanded to the 48-biy E(Ro) such that E(Ro) = 6f80fe8al7a9. 

The key-dependent function I’; is computed by XORing E(Ro) with the first round key 
K,, such that 


IT, = E(Ro) ® Ky 
= 4821976f9a73 
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Figure 3.4 Block cipher design of DES. 
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This 48-bit I, is first divided into eight six-bit blocks, and then fed into eight S;-boxes. 
The output Q, resulting from the S-box substitution phase is computed as Q; = alec96lc. 

Using Table 3.7, the permuted values of Q; are P(Q)) = 2bal536c. Modulo-2 addition 
of P(&2;) with Lo becomes 


R, = P(Q)) G Lo 
= 85baf2e5 
Since L; = Ro, this gives L, = dcl1fl0f4. 


Consider next the second-round encryption. Expanding R, with the aid of Table 3.5 
yields E(R,) = cObdf57a570b. XORing E(R,) with K, produces 


Iz = E(R)) ® Ko 
= 1la2c28ade043 


The substitution operations with S-boxes yields the 32-bit output Q2 such that Q2 = 
lebcebdf. Using Table 3.7, the permutation P(Q2) becomes P(Q22) = 5f3e39f7. Thus, the 
right-half output R. after round two is computed as 


Ry = P(Q2) @ Ly 
= 83212903 


The left-half output L, after round two is immediately obtained as 
Ly = R, = 85baf2e5 


Concatenation of Ry with L2 is called the preoutput block in our two-round cipher system. 
The preoutput is then subjected to the inverse permutation of Table 3.8. Thus, the output 
of the DES algorithm at the end of the second round becomes the ciphertext Y: 


Y = IP™'(Ro||L2) 
= d7698224283e0aea 


3.1.4 DES Decryption 


The decryption algorithm is exactly identical to the encryption algorithm except that the 
round keys are used in the reverse order. Since the encryption keys for each round are 
K,, Ko, ..., Ky, the decryption keys for each round are K16, Ks, ..., K,. Therefore, the 
same algorithm works for both encryption and decryption. The DES decryption process 
will be explained in the following example. 


Example 3.3 Recover the plaintext X from the ciphertext Y = d7698224283e0aea (com- 
puted in Example 3.2). Using Table 3.4 in the first place, divide the ciphertext Y into the 
two blocks: 
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R> = 83212903 
Ly = 85baf2e5 


Applying Table 3.5 to Lz yields E(L2) = cObdf57a570b. 
E(L2) is XORed with K» such that 


Ty = E(L2) @ K2 
= la2c28ade043 


This is the 48-bit input to the S-boxes. 

After the substitution phase of S-boxes, the 32-bit output Q, from the S-boxes is 
computed as Q 2 = lebcebdf. From Table 3.7, the permuted values of Q2 are P(Q2) = 
5f3e39f7. 

Moving up to the first round, we have L; = P(Q22) @ Ro = del fl0f4. 

Applying Table 3.5 for L; yields E(L;) = 6f80fe8al7a9. 
XORing E(L;) with K,, we obtain the 48-bit input to the S-boxes. 


Ty =E(L1) @ ki 
= 4821976f9a73 


The 32-bit output from the S-boxes is computed as: 
Q, = alec96lc 
Using Table 3.7 for permutation, we have 
P(Q)) = 2bal536c 
The preoutput block can be computed as follows: 
Lo = P(Q)) ® Rj = aelbal89 
Ro = L; = del fl0f4 
Lo||Ro = aelbal89dc1f10f4 (preoutput block) 
Applying Table 3.8 (IP~!) to the preoutput block, the plaintext X is restored as follows: 
X = IP“! (LollRo) 
= 3570e2f1ba4682c7 


Example 3.4 Consider the encryption problem of plaintext 


X = 785ac3a4bd0fel2d with the original input key 
K = 38a84ff898b90b8f. 
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The 48-bit round keys from K, through Kj» are computed from the 56-bit key blocks 
through a series of permutations and left shifts, as shown below: 


Compressed round keys 


K, = 034b8fccfd2e 
K3 = 5b9cOcca7c70 
Ks = 34ec2e915e9a 
K7 = 68ae35936aec 
Koy = c043eebe209d 
Ki, = 851b6336a3a3 
K13 = 1d57c04ea3da 
Ky5 = 9dc1456a946a 


K» = 6e26890ddd29 
K4 = 48a8dae9cb3c 

Ko = e22d02dd1235 
Kg = c5b41a30bb95 

Ko = b0d331a373c7 
Kj. = a372d5f60d47 
Ky4 = 5251f975£549 
Ki5 = 9f2dla5ad5fa 





The 64-bit plaintext X splits into two blocks (Lo, Ro), according to Table 3.4 (IP), 


such that 


Lo = 4713b8f4 
Ro = 5cd9b326 


The 32-bit Ro is spread out and scrambled in 48 bits, using Table 3.5, such that E(Ro) = 


2f96f3da690c. 


The 48-bit input to the S-box, I), is computed as: 


I, =E(Ro) ® Ky 
= 2cdd7c169422 


The 32-bit output from the S-box is Q) = 28e8293b. 
Using Table 3.7, P(&2,) becomes 


P(Q1) = la0b2fc4 


XORing P(Q;) with Lo yields 


R; = P(Q)) ® Lo 
= 5d189730 


which is the right-half output after round one. 


Since L; = Ro, the left-half output L, after round one is L; = 5cd9b326. The first 


round of encryption 


has been completed. 


In similar fashion, the 16-round output block (L;, Rj), 2 < i < 16, can be computed 


as follows: 
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Table for encryption blocks (L;, R;), 1 <i < 16 


i L; R; 
1 5cd9b326 5d189730 
2 5d189730 e0e7a039 
3 e0e7a039 61123d5d 
4 61123d5d a6f2958 1 
5 a6f2958 1 clfeOf05 
6 clfe0f05 8e6f6798 
7 8e6f6798 6bc34455 
8 6bc34455 ec6dlab8 
9 ec6dlab8 d0d10423 
10 d0d10423 56a0e201 
11 56a0e201 b6c73726 
12 b6c73726 6ff2ef60 
13 6ff2ef60 f04bflad 
14 f04bflad £0d35530 
15 £0d35530 07b5cf74 


16 O7bScf74 O9ef5b69 


The preoutput block (Rj6, Li6) is the concatenation of Rj6 with Lis. Using Table 3.8 
(IP-'), the ciphertext Y, which is the output of the DES, can be computed as: 


Y = fd9cba5d26331f38 


Example 3.5 Consider the decryption process of the ciphertext 
Y = fd9cba5d26331f38 which was obtained in Example 3.4. Applying Table 3.4 (IP) 
to the 64-bit ciphertext Y, the two blocks (Rj.6, Li6) after swap yields 


Rig = 07b5cf74, 
Li6 = 09ef5b69 
Expansion of Rj6: E( Ris) = 00fdabeSeba8 
S-box input: 16 = E(Ri6) ® K16 
= 9fd0b1bf3e52 


S-box output: Qi6 = 2e09ee9 
Permutation of Qyg: P(Q 6) = f93c0e59 
The left-half output Rs after round sixteen: 


Ris = P(XQi6) ® Lis 
= f0d35530 


Since L15 = Rj, the right-half output L)5 is Ly5 = O7b5cf74. 
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Thus, the 16-th round decryption process is accomplished counting from the bot- 
tomup. In a similar fashion, the rest of the decryption processes are summarised in the 
following table. 


Table for decryption blocks (R;, Lj), 15 <i <0 


i Ry L; 
15 F0d35530 0765cf74 
14 FO4bflad f0d35530 
13 6ff2ef60 f04bflad 
12 b6c73726 6ff2ef60 
11 56a0e201 b6c73726 
10 d0b10423 56a0e201 
9 ec6dlab8 d0b10423 
8 6bc34499 ec6dlab8 
7 8e6f6798 6bc34499 
6 clfeOf05 8e6f6798 
5 a6f29581 clfeOf05 
4 61125d5d a6f29581 
3 e0e7a039 61125d5d 
2 5d189730 e0e7a039 
1 5cd9b326 5d189730 
0 4713b8f4 5cd9b326 


The preoutput block is (Ro|| Lo) = 4713b8f45cd9b326. 
Using Table 3.8 (IP~'), the plaintext is recovered as X = 785ac3a4bd0fel2d. 


3.1.5 Triple DES 


Triple DES is popular in Internet-based applications, including PGP and S/MIME. The 
possible vulnerability of DES to a brute-force attack brings us to find an alternative 
algorithm. Triple DES is a widely accepted approach which uses multiple encryption 
with DES and multiple keys, as shown in Figure 3.5. The three-key triple DES is the 
preferred alternative, whose effective key length is 168 bits. 

Triple DES with two keys (KI = K3, K2) is a relatively popular alternative to DES. 
But triple DES with three keys (K1, K2, K3) is preferred, as it results in a great increase 
in cryptographic strength. However, this alternative raises the cost of the known-plaintext 
attack to 2!68, which is beyond what is practical. 

Referring to Figure 3.5, the ciphertext C is produced as 


C = Ex3[Dxo[Exi (P)]] 


The sender encrypts with the first key K1, then decrypts with the second key K2, and 
finally encrypts with the third key K3. Decryption requires that the keys are applied in 
reverse order: 


P = DxilEx2[Dx3(©)]] 
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Figure 3.5 Triple DES encryption/decryption. 


The receiver decrypts with the third key K3, then encrypts with the second key K2, 
and finally decrypts with the first key K1. This process is sometimes known as Encrypt- 
Decrypt-Encrypt (EDE) mode. 


Example 3.6 Using Figure 3.5, the triple DES computation is considered here. 
Given three keys: 


K1 = 0x260b152f31b51c68 
K2 = 0x321f0d61a773b558 
K3 = 0x519b7331bf104ce3 


and the plaintext P = 0x403da8a295d3fed9 
The 16-round keys corresponding to each given key K1, K2 and K3 are computed as 


shown below. 


Round Kl K2 K3 

1 000ced9158c9 S5alec4b60e98 03e4ee7c63c8 
2 588490792e94 710c318334c6 8486dd46ac65 
3 54882eb9409b c5a8b4ec83a5 575a226a8ddc 
4 a2a006077207 96a696124ecf aab9e009d59b 
5 280e26b62 1e4 7e16225e9191 98664f4f542 1 

6 e03038a08bc7 ea906c836569 615718ca496c 
7 88c25e6abb00 4499e580db9c 


848670562693 
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Round Kl K2 K3 

8 c65al27f0549 245b3af0453e 93e853d116b1 

9 2443236696a6 76d38087dd44 cc4al fa9f254 
10 a311155cOdeb 1a915708a7f0 27b30c3 1c6a6 
11 0d02d10ed859 2d405ff9cc05 Oalce39c0c87 
12 1750b843£570 2741ac4a469a £968788e62d5 
13 9e01c0a98d28 9a09b19d710d 84e78833e3cl 
14 la4a0dc85el16 9d2a39a252e0 521f17b28503 
15 093 10c5d42be 87368cd0ab27 6db841ce2706 
16 53248c80ee34 30258f25cl1d c9313c0591e3 
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Encryption: Compute the ciphertext C through the EDE mode operation of P. Each stage 
in the triple DES-EDE sequence is computed as: 


First stage: Ex; = 0x7a39786f7ba32349 
Second stage: Dx2 = 0x9c60f85369113aea 
Third stage: Ex3 = 0xe22ae33494beb930 = C (ciphertext) 


Decryption: Using the ciphertext C obtained above, the plaintext P is recovered as: 


Forth stage: Dx3 = 0x9c60f85369113aea 
Fifth stage: Ex = 0x7a39786f7ba32349 
Final stage: Dx, = 0x403da8a295d3fed9 = P (plaintext) 


3.1.6 DES-CBC Cipher Algorithm with IV 


This section describes the use of the DES cipher algorithm in Cipher Block Chaining 
(CBC) mode as a confidentiality mechanism within the context of the Encapsulating 
Security Payload (ESP). ESP provides confidentiality for IP datagrams by encrypting the 
payload data to be protected (see Chapter 7). 

DES-CBC requires an explicit Initialisation Vector (IV) of 64 bits that is the same 
size as the block size. The IV must be a random value which prevents the generation 
of identical ciphertext. [V implementations for inner CBC must not use a low Hamming 
distance between successive IVs. The IV is XORed with the first plaintext block before 
it is encrypted. For successive blocks, the previous ciphertext block is XORed with the 
current plaintext before it is encrypted. 

DES-CBC is a symmetric secret key algorithm. The key size is 64 bits, but it is 
commonly known as a 56-bit key. The key has 56 significant bits; the least significant bit 
in every byte is the parity bit. 

There are several ways to specify triple DES encryption, depending on the decision 
which affects both security and efficiency. For using triple encryption with three different 
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Figure 3.6 Triple DES-EDE in CBC mode. 


keys, there are two possible triple-encryption modes (i.e. three DES-EDE modes): inner 
CBC and outer CBC, as shown in Figure 3.6. 


Inner CBC 

This mode requires three different IVs. 
So = Exi (Pi © (IV)1), To = Exi(P2 @ So), Ro = Exi(P3 © To) 
Si = Dx2(So @ (IV)2), Ti = Dx2(To © Si), Ri = Dx2(Ro © T1) 
Cy = Ex3(S; @ (IV)3), Co = Ex3(T: ® Ci), C3 = Ex3(Ri @ C2) 
Outer CBC 

This mode requires one IV. 
Cy = Ex3(Dx2(Exi (P: 6 IV))) 
Cy = Ex3(Dx2(Exi (P2 © Ci))) 
C3 = Ex3(Dx2(Exi (P3 © C2))) 
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Example 3.7 Consider the triple DES-EDE operation in CBC mode being shown in 
Figure 3.6(b). 
Suppose three plaintext blocks P,, P2 and P3, and IV are given as: 


P; = 0x317f2147a6d50c38 
Py = 0xc6115733248f702e 
P3 = 0x1370f341da552d79 
and IV = 0x714289e53306f2e1 


Assume that three keys K1, K2 and K3 used in this example are exactly the same keys 
as those given in Example 3.6. The computation of ciphertext blocks (C;, C2, C3) at each 
EDE stage is shown as follows: 


(1) CC, computation with first EDE operation 

P; @IV = 0x403da8a295d3fed9 

Exi(Pi @ IV) = 0x7a39786f7ba32349 

Dx2(Exi (Pi @ IV)) = 0x9c60f853691 13aea 

C, = Ex3(Dx2(Exi (P; @ IV))) = 0xe22ae33494beb930 
(2) C, computation with second EDE operation 

Py @ C; = 0x243bb407b03 1c9 le 

Exi(P2 ® Ci) = Oxfeb7c33e747abf74 

Dx2(Exi(P2 @ Ci)) = 0x497£548f78af6e6f 

Cy = Ex3(Dx2(Exi (P2 © Ci))) = 0xe4976149del5cal76 
(3) C3 computation with third EDE operation 

P3 @ Cy = Ox5a06e7dc3b098c0f 

Ex; (P3 ® C2) = 0x0eb878e2680e7f78 

Dx2(Exi(P3 @ C2)) = 0xc6c8441ee3b5ddic 

C3 = Ex3(Dx2(Exi (P3 @ C2))) = Oxf980690fc2db462d 


Thus, all three ciphertext blocks (C;, C2, C3) are obtained using the outer CBC mechanism. 


3.2 International Data Encryption Algorithm (IDEA) 


In 1990, Xuejia Lai and James Massey of the Swiss Federal Institute of Technology 
devised a new block cipher. The original version of this block-oriented encryption algo- 
rithm was called the Proposed Encryption Standard (PES). Since then, PES has been 
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strengthened against differential cryptographic attacks. In 1992, the revised version of PES 
appeared to be strong and was renamed as the International Data Encryption Algorithm 
(IDEA). IDEA is a block cipher that uses a 128-bit key to encrypt 64-bit data blocks. 

Pretty Good Privacy (PGP) provides a privacy and authentication service that can be 
used for electronic mail and file storage applications. PGP uses IDEA for conventional 
block encryption, along with RSA for public-key encryption and MD5 for hash coding. 
The 128-bit key length seems to be long enough to effectively prevent exhaustive key 
searches. The 64-bit input block size is generally recognised as sufficiently strong enough 
to deter statistical analysis, as experienced with DES. The ciphertext depends on the 
plaintext and key, which are largely involved in a complicated manner. IDEA achieves 
this goal by mixing three different operations. Each operation is performed on two 16-bit 
inputs to produce a single 16-bit output. IDEA has a structure that can be used for both 
encryption and decryption, like DES. 


3.2.1. Subkey Generation and Assignment 


The 52 subkeys are all generated from the 128-bit original key. IDEA algorithm uses 52 
16-bit key sub-blocks, i.e. six subkeys for each of the first eight rounds and four more 
for the ninth round of output transformation. 

The 128-bit encryption key is divided into eight 16-bit subkeys. The first eight subkeys, 
labelled Z), Zo, ..., Zg are taken directly from the key, with Z, being equal to the first 
16 bits, Z to the next 16 bits, and so on. The first eight subkeys for the algorithm 
are assigned such that the six subkeys are for the first round, and the first two for the 
second round. After that, the key is circularly shifted 25 bits to the left and again divided 
into eight subkeys. This procedure is repeated until all 52 subkeys have been generated. 
Since each round uses the 96-bit subkey (16 bit x 6) and the 128-bit subkey (16 bits x 8) 
is extracted with each 25-bit rotation of the key, there is no way to expect a simple 
shift relationship between the subkeys of one round and that of another. Thus, this key 
schedule provides an effective technique for varying the key bits used for subkeys in the 
eight rounds. Figure 3.7 illustrates the subkey generation scheme for making use of IDEA 
encryption/decryption. 

If the original 128-bit key is labelled as Z(1, 2, ..., 128), then the entire subkey blocks 

of the eight rounds have the following bit assignments (see Table 3.9). 
Only six 16-bit subkeys are needed in each round, whereas the final transformation uses 
four 16-bit subkeys. But eight subkeys are extracted from the 128-bit key with the left 
shift of 25 bits. That is why the first subkey of each round is not in order, as shown in 
Table 3.9. 


Example 3.8 Suppose the 128-bit original key Z is given as 


Z=(5al4 fb3e O21lc 79e0 6081 46a0 117b— ff03) 


The 52 16-bit subkey blocks are computed from the given key Z as follows: for the first 
round, the first eight subkeys are taken directly from Z. After that, the key Z is circularly 
shifted 25 bits to the left and again divided into eight 16-bit subkeys. These shift-divide 
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Figure 3.7. IDEA encryption/decryption block diagrams. 


procedures are repeated until all 52 subkeys are generated, as shown in Table 3.9. The 
IDEA encryption key is computed as shown in Table 3.10. 


3.2.2 IDEA Encryption 


The overall scheme for IDEA encryption is illustrated in Figure 3.8. As with all block 
ciphers, there are two inputs to the encryption function, i.e. the plaintext block and encryp- 
tion key. IDEA is unlike DES (which relies mainly on the XOR operation and on nonlinear 
S-boxes). In IDEA, the plaintext is 64 bits in length and the key size is 128 bits long. 
The design methodology behind the IDEA algorithm is based on mixing three different 
operations. These operations are: 


® Bit-by-bit XOR of 16-bit sub-blocks 
Addition of 16-bit integers modulo 2'° 
© Multiplication of 16-bit integers modulo 2!° + 1 


IDEA utilises both confusion and diffusion by using these three different operations. For 
example, for the additive inverse modulo 2!°, —Z; Z; = 0 where the notation —Z; 
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Table 3.9 Generation of IDEA 16-bit subkeys 








Round 1 

Z, = Z(1,2,..., 16) Z4 = Z(49, 50, ..., 64) 

Zo = Z(17, 18, ..., 32) Zs = Z(65, 66, ..., 80) 

Z3 = Z(33, 34, ..., 48) Z6 = Z(81, 82, ..., 96) 
Round 2 

Zr = Z(97, 98, ..., 112) Zio = Z(42, 43, ..., 57) 

Zg = Z(113, 114,..., 128) Zi. = Z(58, 59, ..., 73) 

Zo = Z(26, 27,...,41) Zi. = Z(74, 75, ..., 89) 
Round 3 

Z13 = Z(90, 91,..., 105) Zi6 = Z(10, 11,..., 25) 

Zi4 = Z(106, 107, ..., 121) Ziq = Z(51, 52, ..., 66) 

Zis = Z(122, 123,...,128,1,2,...,9) Zig = Z(67, 68, ..., 82) 
Round 4 

Zio = Z(83, 84, ..., 98) Zn = Z(3,4,..., 18) 

Zp = Z(99, 100, ..., 114) Zo3 = Z(19, 20, ..., 34) 

Zn = Z(115, 116, ..., 128, 1, 2) Zo4 = Z(35, 36, ..., 50) 
Round 5 

Zos = Z(76, 77, ..., 91) Zog = Z(124, 125,..., 128, 1,2,..., 11) 

Zo6 = Z(92, 93, ..., 107) Zo9 = Z(12, 13, ..., 27) 

Zo = Z(108, 109, ..., 123) Z3 = Z(28, 29, ..., 43) 
Round 6 

Z3; = Z(44, 45, ..., 59) Z34 = Z(117, 118,..., 128, 1,2, 3, 4) 

Zao = Z(60, 61, ..., 75) Za5 = Z(5, 6,..., 20) 

Z33 = Z(101, 102,..., 115) Zag = Z(21, 22, ..., 36) 
Round 7 

Z37 = Z(37, 38, ..., 52) Za = Z(85, 86, ..., 100) 

Z3g = Z(53, 54, ..., 68) Za, = Z(126, 127, 128,...,1,2,..., 13) 

Z39 = Z(69, 70, ..., 84) Zan = Z(14, 15,..., 29) 
Round 8 

Zaz = Z(30, 31, ..., 45) Zag = Z(78, 79, ...,93) 

Za4 = Z(46, 47, ..., 61) Zaz = Z(94, 95, ..., 109) 

Zas = Z(62, 63,...,77) Zag = Z(110, 111,..., 125) 

Round 9 (final transformation stage) 
Zag = Z(23, 24, ..., 38) Zs, = Z(55,56,..., 70) 
Zs = Z(39, 40, ..., 54) Zs. = Z(71, 72, ..., 86) 


denotes the additive inverse; for the multiplicative inverse modulo 2! 41, Z;OZ;, a | 
where the notation Z;' denotes the multiplicative inverse. 

In Figure 3.8, IDEA algorithm consists of eight rounds followed by a final output 
transformation. The 64-bit input block is divided into four 16-bit sub-blocks, labelled 
X 1, Xz, X3 and X4. These four sub-blocks become the input to the first round of IDEA 
algorithm. The subkey generator generates a total of 52 subkey blocks that are all gener- 
ated from the original 128-bit encryption key. Each subkey block consists of 16 bits. The 
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Table 3.10 Subkeys for encryption 








Z, = 5al4 Zo7 = dff8 
Zo = fb3e Zog = ladO 
Z3 = 02Ic Zo9 = a7d9 
Z4 = 79e0 Z30 = £010 
Zs = 6081 Z3, = e3cf 
Z6 = 46a0 232 = 0304 
Z7 = 117b Z33 = 17bf 
Zs = ff03 Z34 = £035 
Zo = 7c04 Z35 = al4f 
Z o= 38f3 Z36 = b3e0 
Zi; = cOcl Z37 = 21c7 
Zy2 = 028d Z3g = 9e06 
Zi3 = 4022 Z39 = 0814 
Zi4 = f7fe Zag = 6a01 
Z 5 = 06b4 Za) = 6b42 
Zi6 = 29f6 Za. = 967 
Z\7 = e781 Z43 = c043 
Zig = 8205 Z44 = 8f3c 
Zi9 = 1a80 Zas = 0c10 
Z0 = 45ef Za6 = 28d4 
Zo = fc0d Za7 = 022f 
Zo2 = 6853 Zag = 7feO 
233 = ecf8 Zag = cf80 
LZ4 = 0871 Z50 = 87le 
Zo5 = 0a35 Z51 = 7818 
Zo = 008b Zs. = 2051 
first round makes use of six 16-bit subkeys (Z), Z2, ..., Zo), whereas the final output 


transformation uses four 16-bit subkeys (Z49, Zso, Zs1, Zs2). The final transformation stage 
also produces four 16-bit blocks, which are concatenated to form the 64-bit ciphertext. 
In each round of Figure 3.8, the four 16-bit sub-blocks are XORed, added and multiplied 
with one another and with six 16-bit key sub-blocks. Between each round, the second 
and third sub-blocks are interchanged. This swapping operation increases the mixing of 
the bits being processed and makes the IDEA algorithm more resistant to differential 
cryptanalysis. 
In each round, the sequential operations will be taken into the following steps: 


(1) X,OZ, 

(2) X24! Z, 

(3) X3 I Z3 

(4) X4OZ, 

(5) (X,OZ)) @ (&3 EH! Z3) = (1) @ (3) 

(6) (X24 Z:) 6 (K1OZ,) = (2) 6 (4) 

(7) (X,OZ)) @ (&3 EH] Z3)OZs = ((1) @ (3))OZs 
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(8) 


(9) 
(10) 
(11) 
(12) 
(13) 
(14) 
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Plaintext X = (X1, X2, X3, X4) 
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Figure 3.8 IDEA encryption scheme. 


(((X2 EH] Z2) @ (X4OZy)) E] (((X, OZ) @ (K3 EH Z3))OZs)) 
= ((2) 6 (4)) EI (C1) @ (3)) OZs) 

(8) © Ze 

(7) 4} (9) = (C1) @ (3)) OZ) EI ((8) OZe) 

(X; OZ) ® ((8)OZe) = (1) @ (9) 

(X3 4] Z3) 6 (9) = (3) @ Y) 

(X I Z,) 6 (10) = (2) @ (10) 

(X4@OZ,) ® (10) = (4) & C10) 
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The output of each round is the four sub-blocks that result from steps 11-14. The two 
inner blocks (12) and (13) are interchanged before being applied to the next round input. 
The final output transformation after the eighth round will involve the following steps: 


(1) Xi; @OZ4p 
(2) XE Zso 
3) X3 Zs 
(4) X4OZsp 


where X;, 1 <i <4, represents the output of the eighth round. As you see, the final ninth 
stage requires only four subkeys, Z49, Z59, Zs; and Zs52, compared to six subkeys for each 
of the first eight rounds. Note also that no swap is required for the two inner blocks at 
the output transformation stage. 


Example 3.9 Assume that the 64-bit plaintext X is given as 
X = (Xj, Xo, X3, X4) = (7fa9 = 1c37 ffb3 ~— df05) 


In the IDEA encryption, the plaintext is 64 bits in length and the encryption key consists 
of the 52 subkeys as computed in Example 3.8. 

As shown in Figure 3.8, the four 16-bit input sub-blocks, X,, X2, X3 and Xq, are 
XORed, added and multiplied with one another and with six 16-bit subkeys. Following 
the sequential operation starting from the first round through to the final transformation 
stage, the ciphertext Y = (Y,, Y2, Y3, Y4) is computed as shown in Table 3.11. 


Table 3.11 Ciphertext computation through IDEA encryption rounds 














Plaintext Input X 
Tfa9 1c37 ffb3 df05 
(X) (X) (X3) (X4) 
Round Round output 
1 C579 F2ff Ofbd Offc 
2 D7a2 80cb 9a61 27¢c5 
3 ab6c e2f9 f3be 36bd 
4 ef5b 9cd2 6808 3019 
5 7e09 2445 d223 d639 
6 4abe d7ac ac8c 8b09 
7 244d 6f5c 4459 3a9c 
8 Of86 7Tb0b S4df T59£ 
9 (final 106b dbfd £323 0876 < Ciphertext Y 


transformation) (Y,) (Y>) (Y3) (Y4) 
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The ciphertext Y represents the output of the final transformation stage: 


Y =(Y1, Yo, Y3, Ys) = (106b  dbfd £323 0876) 


3.2.3. IDEA Decryption 


IDEA decryption is exactly the same as the encryption process, except that the key sub- 
blocks are reversed and a different selection of subkeys is used. The decryption subkeys 
are either the additive or multiplicative inverse of the encryption subkeys. The decryption 
key sub-blocks are derived from the encryption key sub-blocks shown in Table 3.12. 
Looking at the decryption key sub-blocks in Table 3.12, we see that the first four decryp- 
tion subkeys at round i are derived from the first four subkeys at encryption round (10 — i), 
where the output transformation stage is counted as round 9. For example, the first four 
decryption subkeys at round 2 are derived from the first four encryption subkeys of round 
8, as shown in Table 3.13. 

Note that the first and fourth decryption subkeys are equal to the multiplicative inverse 
modulo (2'° + 1) of the corresponding first and fourth encryption subkeys. For rounds 2 
to 8, the second and third decryption subkeys are equal to the additive inverse modulo 2!° 
of the corresponding subkeys’ third and second encryption subkeys. For rounds | and 9, 
the second and third decryption subkeys are equal to the additive inverse modulo 2'° of 


Table 3.12 IDEA encryption and decryption subkeys 





Round Encryption subkeys Decryption subkeys 
1 Z Zz Z3 Z4 Zs Le Zig — Zso — Zs1Z5y Za7Zag 
2 Z; Zs Zy Zio Zi Zio Zi — Zas — ZaaZag ZaiZaa 
3 Z13 Z14 Z15 Zio Zi7 Zig Z3, — Z39 — ZagZag 235236 
4 Zi9 Zo9 Zo Zr. Z23 Zo4 Z3, — Z33 — Z32Z3y Zo9Z0 
is) Zo25 Z26 Z27 Z23 Z29 Z30 L553 — Zo7 — Zo6Z5g Zo3Zn4 
6 Z31 Z32 Z33 Z34 Z35 Z36 Zio — Za — Zo0Z5p ZZ 
7 Z37 Z3g Z39 Zao Za, Zar Zig — Zis — ZigZig ZiuZi2 
8 Z43 Zag Zs Zag Za7 Zags Z,| — Zo — ZgZig ZsZe 
9 Zag Zsq Zs, Zs52 Z,!—Z,—Z;Z;' 


Table 3.13 Decryption subkeys derived from encryption subkeys 


Round i First four decryption Round (10 — i) First four encryption 
subkeys at i subkeys at (10 — i) 
1 Ziy — Z50 — ZsiZ55 Zag Zsq Z51 Zs2 
2 Zi3 — Las — Laslig Za3 Za Zs Zag 
8 Z,' — Zo — ZgZip Z_ Ze Zo Zio 
9 Z,' -Z.-ZsZ; Z, Zo Z3 Za 
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the corresponding second and third encryption subkeys. Note also that, for the first eight 
rounds, the last two subkeys of decryption round 7 are equal to the last two subkeys of 
encryption round (9 — 7) (see Table 3.12). 


Example 3.10 Using Table 3.12, compute the decryption subkeys corresponding to the 
encryption key sub-blocks obtained in Table 3.10. The IDEA decryption key is computed 
as shown in Table 3.14. 
IDEA decryption is exactly the same as the encryption process, but the decryption subkeys 
are composed of either the additive or multiplicative inverse of the encryption subkeys, 
as indicated in Table 3.12. 

The IDEA decryption scheme for recovering plaintext is shown in Figure 3.9. 


Example 3.11 Restore the plaintext X = (7fa9 1c37  ffb3 df05) using the cipher- 
text Y = (106b dbfd £323 0876) that was computed in Example 3.9. 

The recovering steps are shown by the round-after-round process as indicated in 
Table 3.15. 
Thus, the recovered plaintext is X = (X;, Xo, X3, X4) = (7fa9 1c37  ffb3 df05). 


Table 3.14 Subkey blocks for decryption 














Zul =9194 —Zoe = f£75 
—Zs = 78e2 Za) = 246 
—Zs5 = 87e8 253 = ecf8 

Zz} =712a Zo4 = 0871 

Za = 022f Zig = 4396 

Zag = TfeO —Zy, = 03f3 

Zi, = a24c —Zn = ball 
—Zys = £3f0 Zn} = dfa7 
—Zy4 = 70c4 Z17 = e781 

Zyg = 3305 Zig = 8205 

Za) = 6b42 i = 18a7 

Zao = 9f67 —~Zy5 = f94c 

Zu} = 579 —Zi4 = 0802 
—Z39 = f7ec Zig = 9al3 
—Z3g = 6lfa Z 1= cOcl 

Zal = bf28 Zip = 028d 

Z35 = al4f Zz =55ed 

Z36 = b3e0 —Zo = 83fc 

Z| =c53c —Zg = 00fd 
—Z33 = e841 Zi = 2cd9 
—Z37 = fcfc Z5 = 6081 

Z3. = 3703 Zo = 4620 

Zo9 = a7d9 Z; | = Odd8 

Zs = £010 ~Zy = 042 

Z5, =ccl4 —Z,; = fde4 





—Zy7 = 2008 Z, = 4fd0 
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Ciphertext Y = (Y1, Y2, Y3, Y4) 
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Figure 3.9 IDEA decryption scheme. 


3.3 RC5 Algorithm 


The RC5 encryption algorithm was designed by Ronald Rivest of Massachusetts Institute 
of Technology (MIT) and it first appeared in December 1994. RSA Data Security, Inc. 
estimates that RCS and its successor, RC6, are strong candidates for potential successors 
to DES. RCS analysis (RSA Laboratories) is still in progress and is periodically updated 
to reflect any additional findings. 
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Table 3.15 Plaintext computation through IDEA decryption steps 














Ciphertext Input Y 
106b dbfd £323 0876 
(Y)) (Y2) (Y3) (Y4) 
Round Round output 
1 24e4 5069 fe98 dfd8 
2 ffb1 b4a0 75b2 0b77 
3 7420 e9e2 2749 00cc 
4 124c 4800 9d5d 9947 
5 9c42 efcb 28e8 70f9 
6 ed80 a415 78c9 bdca 
7 dca8 8bcl £202 48a6 
8 3649 Olcf 1775 1734 
9 (final Tfa9 1c37 ffb3 df05 — Recovered 
transformation) (X)) (X) (X3) (X4) Plaintext X 


3.3.1. Description of RC5 


RC5 is a symmetric block cipher designed to be suitable for both software and hardware 
implementation. It is a parameterised algorithm, with a variable block size, a variable 
number of rounds and a variable-length key. This provides the opportunity for great 
flexibility in both performance characteristics and the level of security. 

A particular RC5 algorithm is designated as RC5-w/r/b. The number of bits in a 
word, w, is a parameter of RCS. Different choices of this parameter result in different 
RC5 algorithms. RCS is iterative in structure, with a variable number of rounds. The 
number of rounds, r, is a second parameter of RCS. RCS uses a variable-length secret 
key. The key length b (in bytes) is a third parameter of RC5. These parameters are 
summarised as follows: 


w: The word size, in bits. The standard value is 32bits; allowable values are 16, 32 and 
64. RCS encrypts two-word blocks so that the plaintext and ciphertext blocks are 
each 2w bits long. 


r: The number of rounds. Allowable values of r are 0, 1, ..., 255. Also, the expanded 
key table S contains t = 2 (r + 1) words. 


b: The number of bytes in the secret key K. Allowable values of b are 0, 1, ..., 255. 
K: The b-byte secret key; K[0], K[1],..., K[b-—1] 


RC5 consists of three components: a key expansion algorithm, an encryption algorithm 
and a decryption algorithm. These algorithms use the following three primitive operations: 


1. Addition of words modulo 2” 
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2. © Bit-wise exclusive-OR of words 
3. <<< Rotation symbol: the rotation of x to the left by y bits is denoted by x <<< y. 


One design feature of RCS is its simplicity, which makes RCS easy to implement. Another 
feature of RCS is its heavy use of data-dependent rotations in encryption; this feature is 
very useful in preventing both differential or linear cryptanalysis. 


Example 3.12 Given RC5-32/16/10. This particular RC5 algorithm has 32-bit words, 
16 rounds, a 10-byte (80-bit) secret key variable and an expanded key table S of t = 2(r + 
1) = 2(16 + 1) = 34 words. Rivest proposed RC5-32/12/16 as a block cipher providing 
a normal choice of parameters, i.e. 32-bit words, 12 rounds, 16-byte (128-bit) secret key 
variable and an expanded key table of 26 words. 


3.3.2 Key Expansion 


The key-expansion algorithm expands the user’s key K to fill the expanded key table S, 
so that S resembles an array of t = 2(r + 1) random binary words determined by K. It 
uses two word-size magic constants P,, and Q,, defined for arbitrary w as shown below: 


P,, = Odd ((e — 2)2”) 
Q,, = Odd ((@ — 1)2”) 


where 


e = 2.71828 ...(base of natural logarithms) 
¢= (14+ J5)/2 = 1.61803... (golden ratio) 
Odd(x) is the odd integer nearest to x. 


First algorithmic step of key expansion: This step is to copy the secret key K[O, 1, ..., 
b — 1] into an array L[0, 1, ..., c — 1] of c = [b/u] words, where u = w/8 is the number 
of bytes/word. 

This first step will be achieved by the following pseudocode operation: for i = b — 1 
down to 0 do L{i/u] = (L[i/u] <<< 8)+ K[i]; where all bytes are unsigned and the 
array L is initially zeroes. 


Second algorithmic step of key expansion: This step is to initialise array S to a particular 
fixed pseudo-random bit pattern, using an arithmetic progression modulo 2” determined 
by two constants P,, and Q,. 


S(O] = Py: 
fori =1tot—1do S[{i] = S[i-1]+ Oy. 


Third algorithmic step of key expansion: This step is to mix in the user’s secret key in 
three passes over the arrays S and L. More precisely, due to the potentially different sizes 
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of S and L, the larger array is processed three times, and the other array will be handled 
more after. 

i=j 


j = 0; 
A=B=0; 


do 3* max (f, c) times: 

A= S[i] = (S[i] + A+ B) <<< 3 
B=L{j) = (LUj]+ 4+ B) <<< (A+ B); 
i= (i+ 1) (mod £); 

j= (+1 (mod c). 


Note that with the key-expansion function it is not so easy to determine K from S, due 
to the one-wayness. 


Example 3.13 Consider RC5-32/12/16. Since w = 32,r = 12 and b = 16, we have 
u = w/8 = 32/8 = 4 bytes/word 


c = [b/u] = [16/4] = 4 words 
t = 2(r + 1) = 2(12 + 1) = 26 words 





The plaintext and the user’s secret key are given as follows: 


Plaintext = eedba521 6d8f4b15 
Key = 91 5f 46 19 be 41 b2 51 63 55 a5 O1 10 a9 ce 91 


1. Key expansion 
Two magic constants 


P32 = 3084996963 = Oxb7e15163 
Q32 = 2654435769 = 0x9e3779b9 


Step 1 
For i = b — 1 down to 0 do L[i/u] = (L[i/u] <<< 8) + K[i] where b = 16, u = 4 and 
L is initially 0. 


L{i/4] = L[3] for i = 15, 14, 13 and 12. 

L[3] = (LI3] <<< 8) + K[15] = 00+ 91 = 91 

L[3] = (LB] <<< 8) + K[14] = 9100 + ce = 91ce 
L[3] = (LIB] <<< 8) + K[13] = 91ce00 + a9 = 91cea9 


*L[3] = (L[3] <<< 8) + K[12] = 91cea900 + 10 = 91cea910 
L{i/4] = L[2] for i = 11, 10,9 and 8. 
L[2] = (L[2] <<< 8) + K[11] = 00+ 01 =01 
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[2] 2] <<< 8) + K[10] = 0100 + a5 = O1a5 
[2] 2] <<< 8) + K[9] = 01a500 + 55 = 01a555 


*L[2] = (L[2] <<< 8) + K[8] = 01a55500 + 63 = 01255563 
L{i/4] = L[1] for i = 7, 6,5 and 4. 
L{1] = (LU) <<< 8)+K[7] = 00+51=51 
L{1] = (L[1] <<< 8) + K[6] = 5100 + b2 = 51b2 
L{1] = (LU <<< 8) + K[5] = 51b200 + 41 = 51b241 


*Lfl] = (L[1] <<< 8) + K[4] = 51624100 + be = 51b241be 
L{i/4] = L[0] for i = 3, 2, 1 and 0. 
L{0] = (L[0] <<< 8) + K[3] = 00 + 19 = 19 
L[0] = (L[0] <<< 8) + K[2] = 1900 + 46 = 1946 
L[O] = (L[0] <<< 8) + K[1] = 194600 + 5f = 19465 


*L[0] = (L[O] <<< 8) + K[0] = 19465f00 + 91 = 19465f91 


L[2] = (LI 
L[2] = (LI 


Thus, converting the secret key from bytes to words (*) yields: 


L[0] = 19465f91 
L[1] = 51b241be 
L[2] = 01a55563 
L[{3] = 91cea910 
Step 2 
S[0] = P32. For i = 1 to 25, do S[i] = S[i — 1] + Q3p: 
S[0] = b7e15163 
S[1] = S[O] + Q3. = b7e15163 + 9e3779b9 = 5618cblc 
S[2] = S[1] + Q3. = 5618cblc + 9e3779b9 = £45044d5 
S[3] = S[2] + Qa. = £45044d5 + 9e3779b9 = 9287be8e 


S[25] = S[24] + Q3 = 8f14babb + 9e3779b9 = 2b4c3474 


When the iterative processes continue up to tf — 1 = 2(r + 1) — 1 = 25, we can obtain the 
expanded key table S as shown below: 


S[0] = b7e15163 S[09] = 47d498e4 S[18] = d7c7e065 
S[1] = 5618cble S[10] = e60c129d S[19] = 75ffSale 

S[2] = £45044d5 S11] = 84438c56 S[20] = 1436d3d7 
S[3] = 9287be8e S[12] = 227b060f S[21] = b26e4d90 
S[4] = 30bf3847 — S[13] = cOb27fc8 — S[22] = 50a5c749 
S[5] = cef6b200 S[14] = 5ee9f981 $23] = eedd4102 
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S[6] = 6d2e2bb9 = S[15] = fd21733a $[24] = 8d14babb 
S[7] = 0b65a572 = S[16] = 9b58ecf3 —-$[25] = 2b4c3474 
S[8] = a99d1f2b = S[17] = 399066ac 


Step 3 
i=j=0;A=B=0; 





3 x max(t, c) = 3 x 26 = 78 times 
A= S[i] = (S[{i] + A+ B) <<< 3 
B= L{j] = (L[j]+ A+B) <<< (A+B) 
i =i + 1(mod 26) 
j =j + 1cmod 4) 
A = S[0] = (b7e15163 + 0+ 0) <<< 3 
= b7e15163 <<< 3 = bf0a8bld 
B = L[0] = (19465f91 + bfOa8bld) <<< (A+ B) 
= d850eaae <<< bf0a8b1d = db0ald55 
A = S[1] = (5618cblc + bf0a8b1d + db0ald55) <<< 3 
= f02d738e <<< 3 = 816b9c77 
B = L[1] = (1b241be + 816b9c77 + db0ald55) <<< (A+B) 
= ae27fb8a <<< S5c75b9cc = 7fb8aae2 
A = S[2] = (f45044d5 + 816b9c77 + 7fb8aae2) <<< 3 
= £5748c2e <<< 3 = aba46177 
B = L[2] = (01a55563 + aba46177 + 7fb8aae2) <<< (A+ B) 
= 2d0261be <<< 2b5d0c59 = 785a04c3 
A = S[3] = (9287be8e + aba46177 + 785a04c3) <<< 3 
= b68624c8 <<< 3 = b4312645 
B = L[3] = Q1cea910 + b4312645 + 785a04c3) <<< (A+B) 
= be59d418 <<< 2c8b2b08 = 59d418be 


A = S[25] = (4e0d4c36 + f66alaaf + 6d7f672f) <<< 3 
= blf6cel4, <<< 3 = 8fb67085, 
B = L[1] = (cdfc2657 + 8f6670a5 + 6d7£672f) <<< (A+B) 
= cb3lfe2b <<< fd35d7d4 = e2beb31f 
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3.3.3 Encryption 


The input block to RCS consists of two w-bit words given in two registers, A and B. The 
output is also placed in the registers A and B. Recall that RC5 uses an expanded key 
table, S[0, 1,...,¢— 1], consisting of t = 2(r + 1) words. The key-expansion algorithm 
initialises § from the user’s given secret key parameter K. However, the S$ table in RC5 
encryption is not like an S-box used by DES. The encryption algorithm is given in the 
pseudocode as shown below: 


A=A+S[0]; 
B=B+4S{(1); 
fori = 1 tor do 


A=((A@B) <<< B) + S[2i]; 
B= ((B @A) <<< A)+ S[2i + 1); 


The output is in the registers A and B. 


Example 3.14 Consider again RC5-32/12/16. To encrypt the 64-bit input block, use of 
the following steps: 


1 Use the expanded key table S[0, 1, ..., 25] already computed in Example 3.13. 


2 Input the plaintext in two 32-bit registers, A and B. 
3 Compute the ciphertext using the RC5 encryption algorithm according to Figure 3.10. 


Encryption process 


Round A B 
0 5c5f001d eaa518ac 
1 aacdcf78 073A3 lfa 
2 b2c9dafc d0506098 
3 362£2508 67cccf55 
4 ace3d838 5£84483d 
5 6ad30720 d77180e6 
6 3cc6723c accd0d34 
7 c2177344 995485 1d 
8 436ee2fe £7702871 
9 fac6db42 91c5af63 
10 6a180397 f63131f5 
11 e07e082e 816fc2b3 
12 ac13cOf7 52892b5b 


Ciphertext = acl3cOf7 52892b5b 


92 INTERNET SECURITY 


3.3.4 Decryption 


RC5 decryption is given in the pseudocode as shown below. 
For i = r down to | do 


B= ((B—S[2i+ 1) >>> A@A 
A=((A— S[2i]) >>> B)@B 
B=B-S{I] 

A=A-—S[0] 


The decryption routine is easily derived from the encryption routine. The RCS encryp- 
tion/decryption algorithms are illustrated as shown in Figures 3.10 and 3.11, respectively. 


Example 3.15 Consider the decryption problem of RC5-32/12/16. To decrypt the ci- 
phertext obtained in Example 3.14, the output of round 11 is inputted into two 32-bit 
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Figure 3.10 RC5 encryption algorithm. 
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A B 
+k -S(2i+ 1] 
+ }¢— -S[2i] 
Gd Repeat for 
uF i rounds 
o> 
Vv Vv 
| }¢— -S[0] + }e— -S[1] 
Vv Vv 
A B 


Figure 3.11 RC5 decryption algorithm. 


registers, A and B, and the following steps are taken according to the RCS decryption 


algorithm. 


Decryption process 


Round A 

12 e07e082e 

11 6a180397 

10 fac6db42 
9 436ee2fe 
8 c2177344 
7 3cc6723c 
6 6ad30720 
5 ace3d838 
4 362£2508 
3 b2c9dafc 
2 aacdcf78 
1 5c5f001d 


B 


816fc2b3 
f63131£5 
91c5af63 
£7702871 
9954851d 
accd0d34 
d77180e6 
5f84483d 
67cccf55 
d0506098 
073a3 1fa 
eaa518ac 


Deciphered plaintext = eedba521 6d8f4b15 
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Example 3.16 Consider RC5-32/16/10. Since w = 32-bit words, r = 16 rounds and 
b = 10-byte key, the parameters to compute are u = w/8 = 4 bytes/word, c = [b/u] = 3 
words in key, and t = 2(r + 1) = 34 words in S. 


Key mixing 


S[O] = ce9e9457 
S[4] = 12f39eef 
S[8] = Ofle2ae7 
S[12] = f67fd8f0 
S[16] = 4516534e 
S[20] = 3e10bde0 
S[24] = ald40dae 
S[28] = e820a877 
S[32] = 7f05f007 


S[1] = 9b2aa851 
S[5] = 66ba64e2 
S[9] = ae384da7 
S[13] = 8ddf1681 
S[17] = 82472626 
S[21] = 4215fa75 
S[25] = 8efl lefl 
S[29] = 1899687c 
S[33] = eef913ed 


S[2] = 37cde42b 
S[6] = aec49188 
S[10] = 9adOa8ed 
S[14] = 3a7c135e 
S[18] = 383c9ba7 
S[22] = f8dfa0lc 
S[26] = d4409560 
S[30] = 011db658 


Encryption 
Round A B 
0 bd7a3978 08b9f366 
1 a8c06bd8 85ed284f 
2 b4bf3585 90fele28 
3 eff03eac 28a2421b 
4 cd58becc Se05cc06 
5 722d5b91 604e64a0 
6 08e31821 5f3a0f83 
7 £944d070 02ca706b 
8 bal7322a £7542d09 
9 be78e241 ae7al379 
10 ae30c3c2 43413d61 
11 d3c39d63 51b85bc0 
12 244fd451 ae140ae0 
13 5e9c7411 02157ae0 
14 44a9b768 d566f0c2 
15 485ad502 e6f6c625 
16 548854 fc 8a20fdla 


Ciphertext = 548854fc 8a20fdla 


Decryption 

Round A B 
16 485ad502 e6f6c625 
15 44a9b768 d566f0c2 
14 Se9c7411 02157ae0 


S[3] = c74caeb7 

S[7] = 4699fa2b 

S[11] = 31200c4f 
S[15] = 22d6c9ed 
S[19] = 1c2074e9 
S[23] = cda35bac 
S[27] = 043199d0 
S[31] = 72062f23 


SYMMETRIC BLOCK CIPHERS 95 


Round A B 


13 244fd451 ae140ae0 
12 d3c39d63 51b85bc0 
11 ae30c3c2 43413d61 
10 be78e241 ae7al379 
9 bal7332a £7542d09 
8 £944d070 02ca706b 
7 08e31821 5f3a0f83 
6 722d5b91 604e64a0 
5 cd58becc S5e05cc06 
4 eff03eac 28a2421b 
3 b4bf3585 90fele28 
2 a8c06bd8 85ed284f 
1 bd7a3978 08b9f366 
0 eedba521 6d8f4615 


Plaintext (deciphered text) = eedba52 6d8f4b15 


3.4 RC6 Algorithm 


RC6 is an improvement to RC5, designed to meet the requirements of increased security 
and better performance. Like RCS, which was proposed in 1995, RC6 makes use of data- 
dependent rotations. One new feature of RC6 is the use of four working registers instead 
of two. While RCS is a fast block cipher, extending it to act on 128-bit blocks using two 
64-bit working registers. RC6 is modified its design to use four 32-bit registers rather 
than two 64-bit registers. This has the advantage that it can be done two rotations per 
round rather than the one found in a half-round of RCS. 


3.4.1. Description of RC6 


Like RC5, RC6 is a fully parameterised family of encryption algorithms. A version of 
RC6 is also specified as RC6-w/r/b where the word size is w bits, encryption consists 
of a number of rounds r, and b denotes the encryption key length in bytes. 

RC6 was submitted to NIST for consideration as the new Advanced Encryption Stan- 
dard (AES). Since the AES submission is targeted at w = 32 and r = 20, the parameter 
values specified as RC6-w/r are used as shorthand to refer to such versions. For all vari- 
ants, RC6-w/r/b operates on four w-bit words using the following six basic operations: 


a+b: Integer addition modulo 2” 
a — b: Integer subtraction modulo 2” 
a ® b: Bitwise exclusive-OR of w-bit words 
a x b: Integer multiplication modulo 2” 
a <<< b: Rotate the w-bit word a to the left by the amount given by the least 
significant lg w bits of b 


96 INTERNET SECURITY 


a >>> b: Rotate the w-bit word a to the right by the amount given by the least signifi 
cant lg w bits of b (where lg w denotes the base-two logarithm of w). 


RC6 exploits data-dependent operations such that 32-bit integer multiplication is effi- 
ciently implemented on most processors. Integer multiplication is a very effective dif- 
fusion, and is used in RC6 to compute rotation amounts so that these amounts are 
dependent on all of the bits of another register. As a result, RC6 has much faster diffusion 
than RCS. 


3.4.2 Key Schedule 


The key schedule of RC6-w/r/b is practically identical to that of RCS-w/r/b. In fact, 
the only difference is that in RC6-w/r/b, more words are derived from the user-supplied 
key for use during encryption and decryption. 

The user supplies a key of b bytes, where 0 < b < 255. Sufficient zero bytes are 
appended to give a key length equal to a non-zero integral number of words; these key 
bytes are then loaded into an array of c w-bit words L[0], L[1],..., L[c — 1]. The number 
of w-bit words generated for additive round keys is 2r + 4, and these are stored in the 
array S(O, 1, ..., 2r +3]. 

The key schedule algorithm is as shown below. 


Key Schedule for RC6-w/r/b 
Input: User-supplied b byte key preloaded into the c-word array L[0, 1, ..., c— 1] 
Number of rounds, r 
Output: w-bit round keys S[0, 1, ..., 2r +3] 
Key expansion: 


Definition of the magic constants 
Py = Odd((e — 2)2”) 

Qw = Odd((¢ — 2)2") 

where 


e = 2.71828182... (base of natural logarithms) 
@ = 1.618033988... (golden ratio) 


Converting the secret key from bytes to words 
for i = b— 1 down to 0 do 


L{i/u] = (L[i/u] <<< 8+ K{[i] 
Initialising the array S 

S[O] = Py 

for i = 1 to 2r +3 do 

S[i] = Sli— 1] + Qu 
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Mixing in the secret key S 
A=B=i=j=0 

v= 3 x max{c, 2r + 4} 

for s = 1 to v do 

{ 

A = S[i] = (S[i]+ A+ B) <<< 3 

B= L{j]=(LL/]+ 4+ B) <<< (A+B) 
i= (+1) mod (27 + 4) 

j=( +1) modc 

} 


3.4.3 Encryption 


RC6 encryption works with four w-bit registers A, B, C and D which contain the initial 
input plaintext. The first byte of plaintext is placed in the least significant byte of A. The 
last byte of plaintext is placed into the most significant byte of D. The arrangement of 
(A, B, C, D) = (B,C, D, A) is like that of the paralleled assignment of values (bytes) on 
the right to the registers on the left, as shown in Figure 3.12. 

The RC6 encryption algorithm is shown below: 


Encryption with RC6-w/r/b 
Input: Plaintext stored in four w-bit input registers A, B,C, D 
Number of rounds, r 
w-bit round keys S[0, 1, ..., 2r +3] 
Output: Ciphertext stored in A, B,C, D 
Procedure :B = B + S[0] 
D=D+4+S{I\] 
fori = 1 tor do 
{ 
t= (Bx 2B+1)) <<< lg w 
u=(Dx 2D+1)) <<< lg w 
A=((A®@t) <<< u)+ S[2i] 
C=((C @u) <<<t)+ S[2i4+ 1] 
(A, B, C, D) = (B,C, D, A) 
} 
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Repeat for 
v v i rounds 
Te S[2i] T — S[2i + 1] 



















































¢— S[2i + 2] 























Figure 3.12 RC6-w/r/b encryption scheme. 


A=A+S[2r +2] 
C=C+S[2r +3] 


Example 3.17 Consider RC6-w/r/b where w = 32,r = 20 and b = 16. Suppose the 
plaintext and user key are given as follows. 


Plaintext:02 13 24 35 46 57 68 79 8a 9b ac bd ce df e0 fl 
Key: O01 23 45 67 89 ab cd ef O1 12 23 34 45 56 67 78 


Key expansion 
Parameters: 


c = 4(number of words in key) 
t = 44(number of words in S) 


u = 4(number of bytes in word) 
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Magic constants: 
Py = b7e15163 
Ow = 9e377969 
Converting the secret key from bytes to words: 


L[0] = 67452301 
L[2] = 34231201 


L{1] = efcdab89 
L[3] = 78675645 


Mixing in the secret key S 


S[0] = 05479d38 S[1] = e4a3e582 S[2] = focc7a4b S[3] = e878faa4 
S[4] = 8ed14980 S[5] = 5f5873fd S[6] = aecO05ae6 S[7] = aafffeld 
S[8] = 6bf8b7e3 S[9] = 64e27682 S[10] = 23c4d46f S[{11] = da521c4b 
S[12] = 662b9392 S[13] = cSlae971 S[14] = be84587a S15] = 473c1481 
S[16] = ab246684 S[17] = b9770047 S[18] = 98327b6a S[19] = 529be229 
S[20] = b992809a S[21] = 79c1fa56 S[22] = 617cd18d S$[23] = lbcb9a08 
S[24] = 8babbbb3 S[25] = Odd061bd S[26] = 8clec8a2 S[27] = 20f286d0 
S[28] = faf8eff4 S[29] = 46b87c92 S[30] = c5096b01 S[31] = dbdcc9b0 
S[32] = d1b212b4 S[33] = dd0f3d38 S[34] = 27c02df3 S[35] = 0fb21526 
S[36] = 46eO0faa6 S[37] = e9d9748f S[38] = e274fdec S[39] = 09ae3f8e 
S[40] = 95f85e40 S[41] = a9f90a40 S[42] = f0e51469 S[43] = 45f060d1 
Encryption 
Using Figure 3.12, compute the ciphertext of RC6-32/20/16. 
Initial value in each register: 
A = 35241302 B= 7eaff47e 
C = bdac9b8a_ D = d684c550 
Encryption process 
Round A B C D 
1 Teaff47e al7a48d4 d684c550 fdbc336a 
2 al7a48d4 Fd35085f fdbc336a 8d81f7b9 
3 fd35085f 9300620e 8d81f7b9 2d144999 
4 9300620e 5013ef46 2d144999 53caa736 
5 5013ef46 8c83dd52 53caa736 ef7cbe5d 
6 8c83dd52 £8754ace ef7cbe5d 8cc61508 
7 £8754ace 49dd0a20 8cc61508 0035d1db 
8 49dd0a20 662fc8cb 0035d1db 7e9553f1 
9 662fc8cb 8fde9634 7e9553f1 84ceecec 
10 8fde9634 Ce5ac268 84ceecec 42aa5994 
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Round A B Cc D 
11 ce5ac268 4a1d83c3 42aa5994 31cdfe66 
12 4ald83c3 113537e5 31cdfe66 5db94923 
13 113537e5 4b1b6674 5db94923 e€3632504 
14 4b1b6674 f60dd47f €3632504 0750ccfe 
15 f60dd47f 95a4e7a0 0750ccfe ble27064 
16 95a4e7a0 442babe9 ble27064 £229c1dc 
17 442babe9 cb3a05f9 f229cldc faddO6ef 
18 cb3a05f9 Ace5dc7b fadd06ef a76a5ba6 
19 4ce5dc7b 3e3439e9 a76a5ba6 f105f04e 
20 3e3439e9 23c61547 f105f04e 183fa47e 


Final value in each register: 


A = 2f194e52 B= 23c61547 
C = 36f6511f D= 183fa47e 


Thus, the ciphertext is computed as: 


52 4e 19 2f 47 15 c6 23 If 51 f6 36 Te a4 3f 18 


3.4.4 Decryption 


RC6 decryption works with four w-bit registers A, B, C, D which contain the initial output 
ciphertext at the end of encryption. The first byte of ciphertext is placed into the least 
significant byte of A. The last byte of ciphertext is placed into the most significant byte 
of D. 

The RC6 decryption algorithm is illustrated as shown below: 

Decryption with RC6-w/r/b 

Input: Ciphertext stored in four w-bit input registers A, B,C, D 

Number of rounds, r 

w-bit round keys S[0, 1, ..., 2r +3] 

Output: Plaintext stored in A, B,C, D 


Procedure:C = C — S[2r + 3] 
A=A-— S[2r +2] 
for i =r down to | do 
{ 
(A, B,C, D) = (D, A, B,C) 
u= (Dx (2D+1)) <<< lg w 
t= (Bx 2B+1)) <<< lg w 
C= ((C — SP2i+ 1] >>>) Ou 
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A=((A—S[2i]) >>>u) Ot 


} 
D=D-—S{I] 
B= B-— S{0] 


The decryption of RC6 is depicted as shown in Figure 3.13. 


Example 3.18 Consider again RC6-32/20/16. Utilising Figure 3.13 for RC6 decryption, 
the input is the ciphertext stored in four 32-bit input registers A, B, C and D. 
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Figure 3.13. RC6-w/r/b decryption scheme. 
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Initial value in each register: 
A = 3e3439e9 =B = 23c61547 
C= f105f04e D = 183fa47e 


Decryption process 


Round A B C D 
1 4ce5dc7b 3e3439e9 a76a5ba6 f105f04e 
2, cb3a05f9 Ace5dc7b fadd06ef a76a5ba6 
3 442babe9 cb3a05f9 f229cldc faddO6ef 
4 95a4e7a0 442babe9 ble27064 f229c1dc 
5 f60dd47f 95a4e7a0 0750ccfe ble27064 
6 4b1b6674 f60dd47f£ €3632504 0750ccfe 
7 113537e5 4b1b6674 5db94923 e€3632504 
8 4ald83c3 113537e5 31cdfe66 5db94923 
9 ce5ac268 4ald83c3 42aa5994 31cdfe66 
10 8fde9634 ce5ac268 84ceecec 42aa5994 
11 662fc8cb 8fde9634 7e9553f1 84ceecec 
12 49dd0a20 662fc8cb 0035d1db 7e9553f1 
13 £8754ace 49dd0a20 8cc61508 0035d1db 
14 8c83dd52 f8754ace ef7cbe5d 8cc61508 
15 5013ef46 8c83dd52 53caa736 ef7cbe5d 
16 9300620e 5013ef46 2d144999 53caa736 
17 fd35085f 9300620e 8d81f7b9 2d144999 
18 al7a48d4 fd35085f fdbc336a 8d81f7b9 
19 Teaff47e al7a48d4 d684c550 fdbc336a 


20 35241302 Teaff47e bdac9b8a d684c550 
Final value in each register 
A = 35241302 B = 79685746 
C = bdac9b8a_ D = fleOdfce 
Thus, the recovered plaintext is computed as: 


02 13 24 35 46 57 68 79 8a 9b ac bd ce df e0 fl 


Example 3.19 Consider RC6-32/20/16. Assume that the plaintext and user key are 
given as follows. 


Plaintext: b267af31 6d8259e7 bl6ac385 f2a072be 
User key: de 37 al fd 84 92 d8 ef e7 14 fl b7 cc 78 3a ad 
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Converting the secret key from bytes to words: 


L{0] = f2baabd4 L[1] = 7372744 


L[2] = ede4db16L[3] 


= 45cOde8b 


Mixing in the secret key S: 


S[O] = 62e429de S[1] = 3bdc27f1 S[2] = daf4elc8 
S[4] = b22edecc S[5] = 509c1331 S[6] = 3487c3db 
S[8] = 5e4c1907 S[9] = 14458ba5 S[10] = 18da3591 
S[12] = 5a76c846 S[13] = 2085c465 S[14] = 78c44fla 
S[16] = cd810b25 S[17] = a4c787e8 S[18] = 4fcc683d 
S[20] = 1d1a587a S[21] = b55757dc S[22] = c3d68827 
S[24] = 094a038c S[25] = 5c4b0c8e S[26] = 4aa837e7 
S[28] = 2e5e3577 S[29] = 305afc61 S[30] = 3e3b932a 
S[32] = 92891917 S[33] = 1982ee95 S[34] = eabbfb7a 
S[36] = 0b0945ad S[37] = 16059bf7 S[38] = a4fcfe21 
S[40] = 3e05d045 S[41] = 5fbe7c05 S[42] = 974646ea 
Encryption: 
Compute the ciphertext of RC6-32/20/16. 
Initial values in registers: 
A = b267af31 B= 6d8a59e7 
C = bl6ac385_ D = f2a072be 
Encryption process 
Round A B C 
1 d06e83c5 OfbeS58ad 2e7c9aat 
2 OfbeS8ad aebf8fe0 82122047 
i) aebf8fe0 leea2af6 4c5209fc 
4 leea2af6 4c0793b9 67 1ab020 
5 4c0793b9 d02f880f 7dcf4468 
6 d02f880f 76e50556 e1f57£20 
7 76e50556 9226cc lb 040efeb0 
8 9226cclb 06a119a3 6bc6f374 
9 06a119a3 85830598 97683738 
10 85830598 1c28dc0a 250fbfe5 
11 1c28dc0a adb7d6c6 c89c019f 
12 adb7d6c6 1911356 c28f0f4b 
13 1911£356 8a0b 16e8 d547cb27 
14 8a0b16e8 O8ddf156 2cld3ae4 
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3] = 16c26209 
7] = 2b8adble 


ST 

S| 

S| 

S[15] = 344b8269 
S[19] = f0d0d987 
S[23] = bfcc8533 
S[27] = ae2430af 
S[31] = 3db9bd11 
S[35] = 4da6c90 

S[39] = aa2c586f 
S[43] = d4af0053 


D 


82122047 
4c5209fc 
671ab020 
Tdcf4468 
e1f57f20 
040efebO 
6bc6f374 
97683738 
250fbfe5 
c89c019f 
c28f0f4b 
d547cb27 
2cld3ae4 
bed49dle 
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Final value in each register: 


A = 96ca69b2. ~B = cel5ebd7 
C = 12ba9583 D = f3ca4bd4 


Thus, the ciphertext is computed as: A||B||C||D = 


96ca69b2_— cel Sebd7 


Decryption: 


A 


O8ddf156 
c77d14d5 
474b1fd6 
327894f2 
438277f7 
f£8422c8 
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B 


c77d14d5 
474b1fd6 
327894f2 
438277f7 
f£8422c8 

cel5ebd7 


12ba9583_  f3ca4bd4 


Cc 


bed49dle 
4fc7085f 
67ffbcff 

99d3105c 
7351c0e7 
3e0b9530 


D 


4fc7085f 
67ffbcff 

99d3105c 
7351c0e7 
3e0b9530 
f3ca4bd4 


The initial values in registers A, B, C and D are output at round 19 at the end of encryption. 


Decryption process 


Round 


pe 
BP OoOoeaernaANBRWN eK 


12 


A 


438277f7 
327894f2 
474b1fd6 
c77d14d5 
O8ddf156 
8a0b16e8 
1911f356 
adb7d6c6 
1c28dc0a 
85830598 
06a119a3 
9226clb 

76e50556 
d02f880f 
4c0793b9 
leea2af6 

aebf8fe0 

Ofbe58ad 
d06e83c5 
b267af3 1 


B 


f£8422c8 
438277f7 
327894 f2 
474b1fd6 
c77d14d5 
O8ddf156 
8a0b16e8 
1911f356 
adb7d6c6 
1c28dc0a 
85830598 
06a119a3 
9226cclb 
76e50556 
d02f880f 
4c0793b9 
leea2af6 
aebf8fe0 
Ofbe58ad 
d06e83c5 


Cc 


735 1c0e7 
99d3105c 
67ffbcff 
4fc7085f 
bed49dle 
2cld3ae4 
d547cb27 
c28f0f4b 
c89c019f 
250fbfe5 
97683738 
6bc6f374 
040efeb0O 
e1f57f20 
Tdcf4468 
671ab020 
4c5209fc 
82122047 
2e7c9aaf 
bl6ac385 


D 


3e0b9530 
7351c0e7 
99d3105c 
67ffbcff 
A4fc7085f 
bed49dle 
2cld3ae4 
d547cb27 
c28f0f4b 
c89c019f 
250fbfe5 
97683738 
6bc6f374 
040efebO 
e1f57f20 
Tdcf4468 
671ab020 
4c5209fc 
82122047 
2e7c9aaf 
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The final decrypted plaintext is: 
b267af31 6d8a59e7 bl6ac385 f2a072be 


Example 3.20 Consider RC6-32/20/24. Suppose the plaintext and user key are given 
as follows: 


Plaintext: 35241302 79685746 bdac9b8a_ fleOdfce 


User key:01 23 45 67 89 ab cd ef 
Ol 12 23 34 45 56 67 78 
89 9a ab be cd de ef f0 


The user supplies a key of b = 24 bytes, where 0 < b < 255. From this key, 2r + 4 = 44 
words are derived and stored in the array S[0,1,...,2r +3]. This array is used in both 
encryption and decryption. 


Key array 


0] = 4d80ade S[1] = c85296a3 S[2] = c7ca853c S[3] = d665bea0 


]= 

|] = 4d34492f 
8] = f9f0f8eb 
12] = 1la28cd0a 
16] = 7d213901 


24] = f17e5188 
28] = 56093cb8 
32] = fed4cbd3 


S[5] = e110bf65 
S[9] = 2275ea3f 
S[13] = 618fbe87 
S[17] = bed7ab73 
S[21] = 0091b3ca 
S[25] = Jec55cf7 


S[33] = 84b3906f 


6] = 9f4acf83 
10] = e5dc8714 
14] = 6fcledeO 
18] = 79ba092e 
2] = 65f970e9 


0] = ab2eaaec 
34] = 8eced9f1 


7] = ed85cb10 
11] = alb4b8b4 
15] = 8eaf634d 
19] = 6179bc8a 
3] = 687e9e94 


1] = d049366f 
35] = e02a2453 


36] = 123b6e03 
0] = 735d2dc1 


S[37] = a6192a81 
S[41] = 97447b58 


38] = 8648252c 
42] = 362b46b2 


39] = b29fbd04 


S 
S 
S 
S 
S 
S 
S 
S[43] = 7c310342 


ST 
S[4 ST ST 
S| ST ST 
S| ST [ 
ST ] ST [ 
S[20] = aa35b6f6 ] S[2 [2 
S[ ] S[26] = fe2c8e93 [27] = 2e7b3dae 
S[ S[29] = ed28fa03 S[3 [3 
ST ] ST [ 
ST ] S| [ 
S|4 ] ST [ 


RC6 works with four 32-bit registers A, B, C and D which contain the initial input 
plaintext as well as the output ciphertext at the end of encryption. Both encryption and 
decryption using RC6-32/20/24 are processed as shown below. 


Initial values in registers: 
A = 35241302 B = 79685746 
C= bdac9b8a_ D = fleOdfce 
Encryption with RC6-32/20/24 
Round A B C D 


0 35241302 7e406224 bdac9b8a ba337671 
1 7e406224 bf73145b ba337671 ae7fec22 

2 bf73145b 8223f9cc ae7fec22 d96ddcb2 
3 8223f9cc 823d1be2 d96ddcb2 8ad786e7 
4 823d1be2 30fa9e le 8ad786e7 3439983d 
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Thus, the output ciphertext at the end of encryption is: 


Round 


pe 
FP OoOoeAearnaANBRWN eK 


12 


A 


30fa9ele 

69de30e7 
1e5076a4 
a3202136 
48cd17be 
89b9dc8a 
e21b47ad 
51ea2335 
£6288913 
74cc2d40 
3cfc9386 
f0cd5501 

£3d82818 
1e600aa7 
f3afO0e5c 

99fe3cb6 


d0298368 0405e519 2ae9521e 
Decryption with RC6-32/20/24 


A 


f3afOe5c 

1e600aa7 
£3d82818 
f0cd5501 

3cfc9386 

74cc2d40 
f6288913 
51ea2335 
e21b47ad 
89b9dc8a 
A48cd17be 
a3202136 
1e5076a4 
69de30e7 
30fa9ele 

823d1be2 
8223f9cc 

bf73145b 
7e406224 
35241302 
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B 


69de30e7 
1e5076a4 
a3202136 
A48cd17be 
89b9dc8a 
e21b47ad 
51ea2335 
f6288913 
74cc2d40 
3cfc9386 
f0cd5501 

£3d82818 
1e600aa7 
f3afOe5c 

99fe3cb6 
0405e519 


B 


99fe3cb6 
f3afOe5c 

1e600aa7 
£3d82818 
f0cd5501 

3cfc9386 
74cc2d40 
f6288913 
51ea2335 
e21b47ad 
89b9dc8a 
A48cd17be 
a3202136 
1e5076a4 
69de30e7 
30fa9ele 

823d1be2 
8223f9cc 
bf73145b 
7e406224 


C 


3439983d 
41340557 
5cbef6d9 
90578218 
36536a30 
6f54b847 
4927a4al 
21e33ea6 
8dfal819 
23c3a852 
99050d00 
4f93af72 
096f38cb 
13e79bec 
38d4defa 
aeb84edc 


d49152f9. 


C 


38d4defa 

13e79bec 
096f38cb 
4f93af72 

99050d00 
23c3a852 
8dfal819 

21e33ea6 
4927a4al 
6f54b847 
36536a30 
90578218 
5cbef6d9 

41340557 
3439983d 
8ad786e7 
d96ddcb2 
ae7fec22 

ba337671 
bdac9b8a 


D 


41340557 
5cbef6d9 
90578218 
36536a30 
6f£54b847 
4927a4al 
21e33ea6 
8dfal819 
23c3a852 
99050d00 
4f93af72 
096f38cb 
13e79bec 
38d4defa 
aeb84edc 
d49152f9 


D 


aeb84edc 
38d4defa 
13e79bec 
096f38cb 
4f93af72 
99050d00 
23c3a852 
8dfal819 
21e33ea6 
4927a4al 
6f£54b847 
36536a30 
90578218 
S5cbef6d9 
41340557 
3439983d 
8ad786e7 
d96ddcb2 
ae7fec22 
ba337671 
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Thus, the final decrypted plaintext is: 


35241302 79685746 bdac9b8a_ fleOdfce. 


3.5 AES (Rijndael) Algorithm 


The Advanced Encryption Standard (AES) specified the Rijndael algorithm which is a 
FIFS-approved cryptographic algorithm developed by Daemen and Rijmen as an AES 
candidate algorithm in 1999. The Rijndael algorithm is a symmetric block cipher that can 
process data blocks of 128 bits using cryptographic keys of 128, 192 and 256 bits. 

In this section, we will cover the algorithm specification such as the key expansion 
routine, encryption by cipher and decryption by inverse cipher. 


3.5.1 Notational Conventions 


e The cipher key for the Rijndael algorithm is a sequence of 128, 196 or 256 bits such 
that the index attached to a bit falls in between the range 0 <i < 128,0 <i < 192 or 
0 <i < 256, respectively. 


e All byte values of the AES Rijndael algorithm are presented by a vector notation 
(b7, be, bs, b4, b3, bz, b}, bo) which corresponds to a polynomial representation as: 


7 
bax? + bex® + bsx> + bax? + b3x3 + box? + bix + bo = > b;x' 
i=0 


For example, (01001011) > x® +23 +x41. 


e If there is an additional bit bg to the left of an eight-bit byte, it will appear immediately 
to the left of the left bracket such as 1(00101110) = 1(2e). 


e Arrays of bytes, ao, a), d42,..., da 5 are defined from the 128-bit input sequence, ipo, 
ip, ip2, .--, 1P126, 1pi27, as follows: 


a9 = (ipo, ip, a) ip7) 
a, = (ips, ipo, ..-,ipis) 


a5 = (ipi20, ipi2, ---, [Pi27) 


where ip, denotes input, for k =0,1,2,..., 127. 
In general, the pattern extended to longer sequence like 192- and 256-bit keys is 
expressed as: 


an = (iPsn, 1Psn+1> sey iPgn+7)> n < 16. 
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e The AES algorithm’s operations are internally performed on a two-dimensional array 
of bytes called the state. The state consists of four rows of bytes. The state array S,.- 
has a row number r, 0 < r < 4, and a column number c, 0 < c < Nb, where Nb bytes 
are the block length divided by 32. 

The input-byte array (ing, in,, ..., injs) at the cipher is copied into the state array 
according to the following scheme: 


Sc =in(r + 4c) forO<r<4and0<c<WNb 
and at the inverse cipher, the state is copied into the output array as follows: 
out(r + 4c) = S,- forO <r <4 and0<c < Nb. 


An individual byte of the state is referred to as either S,. or S(r,c). The cipher and 
inverse cipher operations are conducted on the state array as illustrated in Figure 3.14. 
For example, if r= 0 and c = 3, then in(0+ 12) = in(12) = So3; if r =3 and 
c = 2, then in(3 + 8) = in(11) = S30. 
The four bytes in each column of the state form a 32-bit word, where the row 
number r provides an index for the four bytes within each word, and the column 
number c provides an index representing the column in this array. 


3.5.2 Mathematical Operations 
Finite field elements (all bytes in the AES algorithm) can be added and multiplied. The 


basic mathematical operations will be introduced in the following. 
Addition 


The addition of two elements in a finite field is achieved by XORing the coefficients for 
the corresponding powers in the polynomials for two elements. For example, 


GP 4272427 4D4 Gt 4¢xetD ax +x tx? 4+x (polynomial) 





























(00101101) 6 (10100011) = (10001110) (binary) 

(2d) @ (a3) = (8e) (hexadecimal) 
Cipher input (bytes) State array Cipher output (bytes) 
ing | ing | ing | inj Soo | Soa | So2 | Sos OUty | Out, | OUtg | Out) 
iny | ins | ing | iny3 Sio | Sia | Sia | Sis out, | outs | OUfg | out); 
ing | ing | ing | inyy Soo | Soa | Soo | So3 OUty | OUute | Out), | Out, 4 
ing | iny | in | inys 53.9 | S31 | S32 | S33 out, | out, | out), | outys 















































Figure 3.14 State array input and output. 
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Multiplication 


The polynomial multiplication in GF(2°) corresponds to the multiplication of polyno- 
mial modulo m(x) that an irreducible (or primitive) polynomial of degree 8 for the 
AES algorithm: 


m(x) =x® +x44+23 +x41 


Example 3.21 Prove (73) e (a5) = (e3) 


(01110011) e (10100101) 

(4x0 txt textile’ 4+2x°42741) 

er ieee ere Lae, De ees aT coe Bae es 
The modular reduction by m(x) results in 


Bee a Pe eNO apg the Od ae oe he et ind Oa ar eh) 
5 ae ee be 
= (11100011) = (e3) 


Since the multiplication is associative, it holds that 
a(x) (d(x) + c(x)) = a(x) b(x) + a(x)e(x) 


The element (01) = (00000001) is called the multiplicative identity. For any polynomial 
b(x) of degree less than 8, the multiplicative inverse of b(x), denoted by b~!(x), can be 
found by using the extended euclidean algorithm such that 


b(x)a(x) + m(x)c(x) = 1 
from which b(x)a(x) mod m(x) = 1. Thus, the multiplicative inverse of b(x) becomes 
b-'(x) = a(x)modm(x). 


The set of 256 possible byte values has the structure of the finite field GF(2*) by means 
of XOR used as both addition and multiplication. 


Multiplication by x 

Let the binary polynomial be b(x) = yoy b;x'. Multiplying b(x) by x results in xb(x) = 
yy bix't!, but it can be reduced by modulo m(x). 

If b; = 1, the reduction is achieved by XORing m(x). It follows that implication by x 
(i.e. (00000010) (2) = (02)(16)) can be implemented at the byte level with a left shift and 
bitwise XOR with (1b). This operation on bytes is denoted by xtime(). Multiplication by 
higher powers of x can be implemented by repeated application of xtime(). 
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Example 3.22 Compute (57) e (13) = (fe) 


(57) = (01010111) 
(57) (02) = xtime(57) = (10101110) = (ae) 
(57) e (04) = xtime(ae) = (01011100) @ (00011011) 
= (01000111) = (47) 
(57) @ (08) = xtime(47) = (10001110) = (8e) 
(57) e (10) = xtime(8e) = (00011100) @ (00011011) = (07) 


Thus, it follows that 


(57) @ (13) = (57) e {(01) @ (02) @ (10)} 
= (57) @ (57) @ (02) @ (57) e (10) 
= (57) ® (ae) (07) 
= (01010111) @ (10101110) @ (00000111) 
= (11111110) = (fe) 


Polynomials with finite field elements in GF(2°) 
A polynomial a(x) with byte-coefficient in GF(2*) can be expressed in word form as: 
a(x) = a3x*° +anx” +a)x +49 & a = (ap, a1, a2, a3) 
To illustrate the addition and multiplication operations, let 
b(x) = b3x? + box? + bx + by & b = (bo, bi, be, b3) 
be a second polynomial. 
Addition is performed by adding the finite field coefficients of like powers of x 
such that 
a(x) + bx) = (a3 @ bs)x? + (az @ ba)x* + (a © bi)x + (Ao @ bo) 
This addition corresponds to an XOR operation between the corresponding bytes in each 
of the words. Multiplication is achieved as shown below: 


The polynomial product c(x) = a(x) e b(x) is expanded and like powers are collected 
to give 


c(x) = a(x) e D(x) = cex® + C5x° + cx" + 03x? + Cox? +cix +co 


= (c6, C5, C4, C3, €2, C1, Co) 
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where 
co = agbo c4 = 03d, @ anb2 © ay b3 
cy = abo B aoby c5 = a3b7 ® arb; 
C2 = anbo @ ab; ® aob2 C6 = a3b3 


c3 = a3bo B anb; G aj bz @ agb3 
The next step is to reduce c(x) mod (x*+ 1) for the AES algorithm, so that x/ mod 
(x4 a 1) = ximod4 | 
The modular product, a(x) ® b(x), of two four-term polynomials a(x) and b(x), is 
given by 
d(x) = a(x) @ b(x) = d3x3 + dhx? +. dix +do 


where 

dy = agbo B a3b, ® azb2 G ajb3 
d| = aybo B agh © a3b2 ® arb; 
dy = azbo B ab, ® aob2 G a3b3 
d3 = a3bo ® arb; © ayb2 G agb3 


Thus, d(x) in matrix form is written as: 


do 903024 bo 
di | _ | aaoa3ay by 
dy | | agajaga3 by 
dy a3424\ a9 bs 


The AES algorithm also defines the inverse polynomials as: 


a(x) = (03)x? + (01)x? + (O1)x! + (02) 
a(x) = (Ob)x* + (Od)x* + (09)x! + (Oe) 


3.5.3 AES Algorithm Specification 


For the AES algorithm, Nb denotes the number of 32-bit words with respect to the 128-bit 
block of the input, output, or state (128 = Nb x 32, from which Nb = 4). 

Nk represents the number of 32-bit words with respect to the cipher-key length of 128, 
192 or 256 bits: 


128 = Nk x 32, Nk=4 
196 = Nk x 32, Nk=6 
256 = Nk x 32, Nk=8 


The number of rounds are 10, 12 and 14, respectively. 
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Key expansion 


The AES algorithm takes the cipher key K and performs a key expansion routine to 
generate a key schedule. The key expansion generates a total of Nb(Nr + 1) words: an 
initial set of Nb words for Nr = 0, and 2Nb for Nr = 1, 3Nb for Nr = 2,..., 11Nb for 
Nr = 10. Thus, the resulting key schedule consists of a linear array of four-byte words 
[wi],0<i < Nb(Nr +1). 

RotWord() takes a four-byte input word [ao, a), a2, a3] and performs a cyclic permu- 
tation such as [a, a2, 43, ag]. 

SubWord() takes a four-byte input word and applies the S-box (Figure 3.15) to each 
of the four bytes to produce an output word. 

Rcon[i] represents the round constant word array and contains the values given by 
[x‘—!, {00}, {00}, {00}] with x‘—! starting i at 1. 


Example 3.23. Compute the round constant words Reon [i]: 
Rcon{i] = [x'~!, {00}, {00}, {00}] 
Rcon[1] = [x°, {00}, {00}, {00}] = [{01}, {00}, {00}, {00}] = 01000000 
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Figure 3.15 AES S-box (FIPS Publication, 2001). 
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x’ ex = xtime(x’) = xtime(80) = fleftshift(80)} @ {1b} = 1b 
Reon[10] = [x°, {00}, {00}, {00}] = [x® e x, {00}, {00}, {00}] = 36000000 
Reon[11] = [x!°, {00}, {00}, {00}] = [x° e x, {00}, {00}, {00}] = 6c000000 
Reon[12] = [x!!, {00}, {00}, {00}] = [x!° x, {00}, {00}, {00}] = d8000000 
Reon[13] = [x!”, {00}, {00}, {00}] = [x'! x, {00}, {00}, {00}] = ab000000 

x! ex = xtime(x!!) = xtime(d8) = {leftshift(d8)} @ {1b} = ab 


Rcon{i] is a useful component for the round constant ward array in order to compute the 
key expansion routine. 

The input key expansion into the key schedule proceeds as shown in Figure 3.16. 
Example 3.24 Suppose the cipher key K is given as 
K = 36 8a cO f4 ed cf 76 a6 08 a3 b6 78 31 31 27 6e 


The first four words of K for Nk =4 results in w[0] = 368acO0f4, w[1] = edcf76a6, 
w[2] = 08a3b678, w[3] = 3131276e. 
Computation of w[4] for i = 4 is as follows: 


Temp = w[3] = 3131276e 
A cyclic permutation of w[3] by one byte produces 


RotWord(w[3]) = 31276e31 
Taking each byte of RotWord(w[3]) at a time and applying to the S-box yields 
SubWord(31276e31) = c7cc9fc7 
Compute a round constant Rceon[i/Nk]: 
Rcon[4/4] = Rceon[1] = 01000000 
XORing SubWord() with Rcon[1] yields 
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Key Expansion(byte key[4*Nk], word w[Nbx(Nr+1)],Nk) 
begin 
i=0 
while (i< Nk) 
w[i]=word[key[4*i],key[4*i+1],key[4*i+2], key[4*i+3] ] 


i=i+1 
end while 
i= Nk 


while (i< Nb*(Nr+1)) 
word temp=w[i-1] 
if (i mod Nk =0) 
temp=SubWord(RotWord(temp)) xor Rcon[i/Nk] 
else if (Nk=8 and i mod Nk=4) 
temp=SubWord (temp) 
endif 
w[i]J=w[i-—Nk] xor temp 
i=i+1 
end while 





end 








Figure 3.16 Pseudocode for key expansion (FIPS Publication, 2001). 


SubWord() @Rcon[1] = c6cc9fc7 
wli — Nk] = w[0] = 368ac0f4 
Finally, w[4] is computed as: 
w[4] = c6cc9fc7 © 368ac0f4 = £0465f33. 


Continuing in this fashion, the remaining w[i], 4 < i < 43, can be computed as shown in 
Table 3.16. 


Cipher 


The 128-bit cipher input is fed in a column-by-column manner, comprising each column 
with a four-byte word. In other words, the input is copied to the state array as shown in 
Table 3.17. 
The cipher is described in the pseudocode in Figure 3.17. 

Individual transformations for the pseudocode computation consist of SubBytes(), 
ShiftRows(), MixColumns() and AddRoundKey(). These transformations play a role in 
processing the state and are briefly described below. 


Table 3.16 AES key expansion 


i 


Temp. 


3131276e 
f0465f33 
1d892995 

152a9fed 
241bb883 
5d2ab305 
40a39a90 
5589057d 
7192bdfe 
165008a6 
56f39236 
037a974b 
72e82ab5 
85b5dde6 
d3464fd0 
d03cd89b 
a2d4f22e 
dd3cecde 
O0e7aa30c 
de467b97 
7c9289b9 
b29bbacc 
bcel19c0O 
62a76257 
le35ebee 
647292be 
d8938b7e 
ba34e929 
a40102c7 
980554f7 
4096df89 
faa236a0 
5ea33467 
891ddlaf 
c98b0e26 
33293886 
6d8a0cel 
cle32993 
086827b5 
3b411£33 


After 
RotWord 


31276e31 


1bb88324 


92bdfe7 1 


e82ab572 


d4f22ea2 


9289b97c 


35ebeele 


0102c7a4 


a334675e 


8a0cel6d 
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After 
SubWord 


c7cc9fc7 


af6cec36 


4f7abba3 


9be5d540 


48893 13a 


4fa75610 


96e92872 


7c771c649 


0a188558 


Tefef83c 


Rcon[i/Nk ] 


01000000 


02000000 


04000000 


08000000 


10000000 


20000000 


40000000 


80000000 


1b000000 


36000000 


After XOR 
with Rcon 


c6cc9fc7 


ad6cec36 


4b7abba3 


93e5d540 


58893 13a 


6fa75610 


d6e92872 


fc77c649 


11188558 


48fef83c 
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w[i] = temp 
®uli — Nk] 


£0465£33 
1d892995 

152a9fed 
241bb883 
5d2ab305 
40a39a90 
5589057d 
7192bdfe 
165008a6 
56f39236 
037a974b 
72e82ab5 
85b5dde6 
d3464fd0 
d03cd89b 
a2d4f22e 
dd3cecdc 
Oe7aa30c 
de467b97 
7c9289b9 
b29bbacc 
bcel19c0O 
62a76257 
le35ebee 
647292be 
d8938b7e 
ba34e929 
a40102c7 
980554f7 
4096df89 
faa236a0 
5ea33467 
891ddlaf 
c98b0e26 
33293886 
6d8a0cel 
cle32993 
086827b5 
3b411f33 
56cb13d2 
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Table 3.17 A 16-byte cipher input array 
Row No. Mapping of input block into 


column-by-column array 
0 ao a4 ag ay\2 
1 ay as ag ay 
2 ay rer a0 a4 
3 a3 ay ay as 


Cipher(byte in [4*Nb], byte out[4*Nb], word w[Nb*(Nr+1)]) 


begin 
byte state[4, Nb] 
state=in 


AddRopundKey (state, w) 


for round=1 step 1 to Nr-1 
SubBytex (state) 
ShiftRows (state) 
MixColumns(state) 
AddRoundKey (state, w+round*Nb) 
end for 


SubBytes (state) 
ShiftRows (state) 
AddRoundKey (state, w+Nr*Nb) 


out=state 
end 











Figure 3.17 Pseudocode for the cipher (FIPS Publication, 2001). 


SubBytes() Transformation 
The SubBytes() transformation is a nonlinear byte substitution that operates independently 
on each byte of the state using a S-box (see Figure 3.18). 

For example, if s2,1 = {8f}, then the substitution value is determined by the intersection 
of the row with index 8 and the column with index f in Figure 3.15. The resulting s, , 
would be a value of {73}. 


Si¢ ———> | S-box | —— SJ’, 


O<rs<3, OSc<SNb-1 





Figure 3.18 SubBytes() transformation by the S-box. 
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ShiftRows() Transformation 
In the ShiftRows(), the first row (row 0) is not shifted and the remaining rows proceed 
as follows: 


yoo 
St,¢ = St,(c4shift(r,Nb)) mod Nb? forO <r <4and0<c < Nb 


where the shift value shift(r, Nb) = shift(r, 4) depends on the row number r as follows: 
shift (1, 4) = 1; shift(2, 4) = 2; shift (3, 4) = 3; 

This has the effect of shifting the leftmost bytes around into the rightmost positions over 
different numbers of bytes in a given row. 


MixColumns() Transformation 

The MixColumns() transformation operates on the state column-by-column, treating each 
column as a four-term polynomial over GF(2’) and multiplied modulo x* + 1 with a fixed 
polynomial a(x) as: 


s'(x) = a(x) @ s(x) 


where a(x) = {03}x? + {O1}x? + {01}x + {02}, s(x) is the input polynomial and s‘(x) is 
the corresponding polynomial after the MixColumns() transformation. 
The matrix multiplication of s’(x) is 


Sd.e 02 03 O1 Ol S0.c 
Sie — Ol 02 O03 OL Sic 
S| O10 102-405 b lagen ree 
53,0 03 O01 O01 02] Ls3¢ 


The four bytes in a column after the matrix multiplication are 


Soc = ({02} © 50,c) ® ({03} © 51.) B 52, B 83, 
Sic = 80,c B ({02} © 81,c) B ({03} ¢ 52.c) B $3, 
55.6 = S0,c B Sic B ({02} © $2,c) ® ({03} © 53,0) 
53. = ({03} © 50,c) ® S1,¢ B S2,¢ B ({02} © 53.) 


AddRoundKey() Transformation 

In AddRoundKey() transformation, a round key is added to the state by a simple bitwise 
XOR operation. Each round key consists of Nb words from the key schedule. These Nb 
words are added into the columns of the state such that 


! ! ! ! 
[Soe Ste 59 o> 53 0] = [So,¢5 S1,c5 S2,c5 53,c] @ [Wround* vb+c [for 0 xc< Nb 


where [w;] are the key schedule words, and round is a value in the range 0 < round < Nr. 
The initial round key addition occurs when round = 0, prior to the first application of the 
round function. The application of the AddRoundKey() transformation to the Nr rounds 
of the cipher occurs when 1 < round < Nr. 
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Example 3.25 Assume that the input block and a cipher key whose length of 16 bytes 
each are given as: 


Plaintext = a3 c5 08 08 78 a4 ff d3 00 ff 36 36 28 5f 01 02 
Cipherkey = 36 8a cO f4 ed cf 76 a6 08 a3 b6 78 31 31 27 6e 
Using the algorithm for the pseudocode computation described in Figure 3.17, the inter- 


mediate values in the state array are given in the following table. The round key values 
w[i] are taken from Example 3.24. 


Cipher (Encrypt) 
r Start of round After After After After XOR 
SubByte ShiftRows MixColumns with w[] 
a3 78 OO 28 95 95 08 19 
0 c5 a4 ff 5f 4f 6b 5c 6e 
08 ff 36 O1 c8 89 80 26 
08 d3 36 02 fe 75 4e 6c 


95 95 08 19 2a 2a 30 d4 2a 2a 30 d4 48 cd af ac b8& dO ba 88 
4f 6b 5c 6e 84 7f 4a Of 7f 4a Of 84 c8 Oc ab la 8e 85 81 Ol 
c8 89 80 26 e8 a7 cd f7 cd f7 e8 a7 24 5e d8 74 7b 77 47 cc 
fe 75 4e 6c bO 9d 2f 50 50 bO 9d 2f 6c b8 06 la Sf 2d eb 99 


b8 dO ba 88 6c 70 f4 c4 6c 70 f4 c4 34 70 8e a4 69 30 db d5 
8e 85 81 O01 19 97 Oc Te 97 Oc Fe 19 4c Ja b7 1b 66 dO 3e 89 
Tb 77 47 cc 21 f5 a0 4b a0 4b 21 f5 89 a0 bY Oc 3a 3a be bl 
Sf 2d eb 99 cf d&8 e9 ee ee cf d& e9 44 52 fl 72 41 c2 8c 8c 


69 30 db d5 f9 04 b9 03 f9 04 b9 03 b7 8e 3e b7 al d8& 3d c5 
66 d9 3e 89 33 35 b2 a7 35 b2 a7 33 58 bb 52 9a 08 48 28 72 
3a 3a be bl 80 80 65 c8 65 c8 80 80 aa a3 6a 87 a2 31 fd ad 
41 c2 8c 8c 83 25 64 64 64 83 25 64 88 6b bd Ze 2e 5d f6 cb 


r Start of round 


94 
00 
6c 


10 


Inverse cipher 


30 
e0 
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After 


SubByte 


04 
el 
e9 
64 


d4 
3e 


22 
81 
e9 
43 


c9 
27 
1d 
32 


5b 
58 
16 
cb 


67 
c7 
4b 
db 


After 


ShiftRows 


94 
el 
a7 
11 


04 
ea 
50 


76 
58 


After 
MixColumns 


a3 
e5 
37 
11 


92 
66 
c9 
69 


48 


f4 
cd 


88 
c8 
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After XOR 


with w[] 


19 
dl 
de 
38 


68 
c4 
ff 
c9 


7b 
d2 
cc 
4b 


2c 
c9 
fd 


The Cipher transformation can be implemented in reverse order to produce a Inverse 
Cipher for the AES algorithm. The individual transformations used in the Inverse Cipher 
are InvShiftRows(), InvSubBytes(), InvMixColumns() and AddRoundKey(). These inverse 


transformations process the state as described in the following. 


InvShiftRows() Transformation 
InvShiftRows() is the inverse of the ShiftRows() transformation. The first row (Row 0) 
is not shifted. The bytes in the last three rows (Row 1, Row 2, Row 3) are cyclically 


shifted over different numbers of bytes as follows: 


shift(r, Nb): shift values, where ris a row number and Nb = 4. 


shift(1, 4) = 1, shift(2, 4) = 2, shift(3, 4) = 3, respectively. 


Specifically, the InvShiftRows() transformation proceeds as: 


/ 
Sp, (cshift(r,Nb))modNb = St,c> for0 <r <4and0<c< Nb 


InvSubBytes() Transformation 


InvSubBytes() is the inverse of the byte substitution transformation, in which the inverse 
S-box is applied to each byte of the state. The inverse S-box used in the InvSubBytes() 
transformation is presented in Figure 3.19. 
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Figure 3.19 AES algorithm Inverse S-box (FIPS Publication, 2001). 


InvMixColumns() Transformation 
InvMixColumns() is the inverse of the MixColumns() transformation. This transformation 
operates column-by-column on the state, treating each column as a four-term polynomial. 
The columns are considered as polynomials over GF(2°) and multiplied modulo x* + 1 
with a fixed polynomial a7!(x). 

If the inverse state s'(x) is written as a matrix multiplication, then it follows: 


s(x) = a7! (x) @ s(x) 


where a~!(x) = {Ob}x3 + {Od}x2 + {09}x + {Oe}. 
The matrix multiplication can be expressed as 


So, Oe Ob 0d 09] [ soc 
sic | | 09 Oe Ob Od |} sy. 
FF 110d: .00~ 06, 0b | I's.) VO Se ANP 


0b Od 09 Oe} | s3. 


53.6 
This multiplication will result in four bytes in a column as follows: 
S0,c = ({0e} © 50,-) B ({Ob} © 51,-) B ({0d} © 52.) B ({09} © 53,.) 

Sic = ({09} © s0,c) B ({Oe} © 51.) B ({Ob} © 52,-) B ({Od} © 53...) 
55,6 = ({0d} © 50,c) B ({09} © 51,<) B ({Oe} © 52.) B ({Ob} © 83,c) 
53, = ({Ob} © 50,c) B ({Od} © 51,-) B ({09} © 52.-) B ({0e} © 53,.) 
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EqInvCipher(byte in[4*Nb], byte out[4*Nb], word dw[Nb*(Nr4+1)]) 
begin 

byte state[4, Nb] 

stae=in 

AddRoundKey(state, dw+ Nr*Nb) 


for round= Nr—1 step —1 to 1 
InvSubBytex (state) 
InvShiftRows (state) 
InvMixColumns(state) 
AddRoundKey (state, dw+round* Nb) 

end for 

InvSubBytex (state) 

InvShiftRows (state) 

AddRoundKey(state, dw) 

out=state 

end 











Figure 3.20 Pseudocode for the inverse cipher (FIPS Publication, 2001). 


Inverse of AddRoundKey() Transformation 
AddRoundKey() is its own inverse because it only involves application of the XOR 
operation. 

For decrypting ciphertext, the Inverse Cipher is described in the pseudocode shown 
in Figure 3.20. 


Example 3.26 The input to the Inverse Cipher is the cipher encryption values obtained 
from Example 3.25. 


Ciphertext = a6 24 62 48 34 dd a8 b9 la fl 73 5d 00 Oe cf 61 
Cipherkey = 36 8a cO f4 ed cf 76 a6 08 a3 b6 78 31 31 27 6e 


The round key values are the same as those used in Example 3.25. The following table 
shows the values in the state array as the Inverse Cipher progresses. 


Inverse Cipher (Decrypt) 


r Start of round After After After XOR After 
InvShiftRows InvSubBytes with w[] InvMixColumns 
a6 34 Ila 00 67 3c 21 56 
0 24 dd fl Oe c7 b5 bO c5 
62 a8 73 cf 4b 8f 6c dec 
48 b9 5d 61 db Oc 6e b3 


67 3c 21 56 67 3c 21 56 Oa 6d 7b bI9 83 a4 48 d4 5b dd 45 dd 
c7 bS5 bO cS cS c7 bS bO O07 31 d2 fe la ba fb 76 58 Ic 8b 88 
4b 8f 6c dc 6c de 4b 8f b8 93 cc 73 69 9d f4 Tf 16 3f f6 2b 
db Oc 6e b3 Oc 6e b3 db 81 45 4b Of 2e 63 cd Ve cb le b2 dd 


122 


r Start of round 


5b 
58 
16 
cb 


c9 
27 
ld 
32 


22) 
81 
e9 
43 


£8 

BS 
80 
89 


4a 
57 
cO0 
91 


32 
52 
54 
lf 


b7 
9a 
87 
Te 


6c 
97 
a0 
ee 


2a 
Tf 
cd 
50 


10 


dd 
Ic 
3f 
le 


4d 
3e 
54 
05 


94 
el 
a7 
11 


6e 
ed 
3a 
91 


le 
ee 
9a 
c4 


61 
34 
95 
31 


04 
b2 
c8 
83 


70 
Oc 
4b 
cf 


45 
8b 
f6 
b2 


d4 
dd 
27 
7a 


04 
ea 
50 
de 


70 
cf 
25 
dd 


34 
77 
18 
e7 


27 
40 
3a 
Ac 


b9 
a7 
80 
25 


£4 
Tc 
21 
d8 


30 
Of 
e8 
9d 


dd 
88 
2b 
dd 


71 
e5 
46 
07 


84 
63 
Sa 
64 


ac 
c9 
fl 
a3 


b7 
ba 
be 
ca 


a6 
30 
c7 
42 


03 
33 
80 
64 


c4 
19 
£5 
e9 


d4 
84 
a7 
2f 


5b 
88 
f6 
le 


c9 
e5 
27 
05 


22 
63 
50 
11 


£8 
c9 
25 
91 


da 
ba 
18 
c4 


32 
30 
3a 
31 


f9 
33 
80 
83 


6c 
19 
21 
cf 


2a 
84 
e8 
b0 


After 
InvShiftRows 


dd 
58 
2b 
b2 


4d 
27 
46 
Ta 


94 
81 
Sa 
de 


45 
lc 
16 
dd 


d4 
3e 
ld 
07 


04 
el 
e9 
64 


70 
ed 
80 
a3 


34 
ee 
c0 
ca 


27 
34 
54 
42 


b9 
b2 
65 
64 


£4 
Oc 
ad 
e9 


30 
4a 
cd 
2f 
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dd 
8b 
3f 
cb 


71 
dd 
54 
32 


84 
ea 
a7 
43 


ac 
cf 
3a 
89 


b7 
77 
9a 
91 


a6 
40 
95 
1f 


03 
a7 
c8 
64 


c4 
Tc 
4b 


57 
97 
d6 
e9 


12 
2a 
3d 
36 


94 
00 
6c 
e3 


el 
12 
c2 


After 
InvSubBytes 


c9 
Se 
Ob 
3e 


65 
3d 
98 
bd 


e7 
91 
46 
9c 


45 
d2 
2b 
c9 


e9 
da 
78 
b0 


ds 
48 
31 
5d 


30 
d9 
3a 
c2 


do 
85 
77 
2d 


95 
6b 
89 
75 


68 
c4 
ff 

c9 


19 
dl 
de 
38 


30 
e0 
eb 
8c 


do 
53 
3a 
71 


28 
99 
If 
10 


3d 
28 
fd 
f6 


db 
3e 
be 
8c 


ba 
81 
47 
eb 


08 
5c 
80 
de 


c9 
ce 


cf 
92 
82 
le 


716 
58 
af 
88 


26 
9b 
d6 
2f 


3c 
2e 
2e 
70 


d9 
75 
e9 
6e 


b7 
58 
aa 
88 


34 
Ac 
89 
44 


48 
c8 
24 
6c 


a3 
c5 
08 
08 


After XOR 


with w[] 


89 
c8 
d4 
b7 


bd 
ae 
13 
c3 


5b 
70 
5f 
Sc 


4b 
a8 
88 
c5 


3a 
9% 
37 
60 


8e 
bb 
a3 
6b 


70 
Ta 
a0 
52 


cd 
Oc 
Se 
b8& 


78 
ad 
ff 

d3 


92 
66 
c9 
69 


a3 
e5 
37 
11 


52 
47 
89 
db 


Oe 
15 
41 
e6 


£8 
a5 
c7 
8b 


3e 
52 
6a 
bd 


8e 
b7 
b9 
fl 


af 
ab 
d8& 
06 


00 
ff 

36 
36 


c9 
27 
ld 
32 


22 
81 
e9 
43 


£8 
b5 
80 
89 


4a 
57 
cO 
91 


32 
52 
54 
lf 


b7 
9a 
87 
Te 


6c 
97 
a0 
ee 


2a 
Tf 
cd 
50 


After 
InvMixColumns 


4d 
3e 
54 
05 


94 
el 
a7 
11 


6e 
ed 
3a 
91 


le 
ee 
9a 
c4 


61 
34 
95 
31 


04 
b2 
c8 
83 


70 
Oc 
4b 
cf 


d4 
dd 
27 
7a 


04 
ea 
50 
de 


70 
cf 
25 
dd 


34 
77 
18 
e7 


27 
40 
3a 
Ac 


b9 
a7 
80 
25 


f4 
Tc 
21 
d8 


30 
Of 
e8 
Od 


71 
e5 
46 
07 


84 
63 
Sa 
64 


ac 
c9 
fl 
a3 


b7 
ba 
be 
ca 


a6 
30 
c7 
42 


03 
33 
80 
64 


c4 
19 
£5 
e9 


d4 
84 
a7 
2f 
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Hash Function, Message Digest and 
Message Authentication Code 


As digital signature technology becomes more widely understood and utilised, many 
countries world-wide are competitively developing their own signature standards for their 
use and applications. 

Some electronic applications utilising digital signatures in electronic commerce (e- 
commerce) include e-mail and financial transactions. E-mail may need to be digitally 
signed, where sensitive information is being transmitted and security services such as 
sender authentication, message integrity and non-repudiation are desired. Financial trans- 
actions, in which money is being transferred directly or in exchange for services and 
goods, could also benefit from the use of digital signatures. Signing the message digest 
rather than the message often improves the efficiency of the process because the message 
digest is usually much smaller than the message. 

In e-commerce, it is often necessary for communication parties to verify each other’s 
identity. One practical way to do this is with the use of cryptographic authentication 
protocols employing a one-way hash function. Division into fixed-bit blocks can be accom- 
plished by mapping the variable-length message on to the suitable-bit value by padding 
with all zeros, including one bit flag and the original message length in hex. Appropriate 
padding is needed to force the message to divide conveniently into certain fixed lengths. 
Several algorithms are introduced in order to compute message digests by employing 
several hash functions. The hash functions dealt with in this chapter are DMDC (1994), 
MDS (1992) and SHA-1 (1995). 


4.1 DMDC Algorithm 


DES-like Message Digest Computation (DMDC) uses a DES variant as a one-way hash 
function. In 1994, this scheme was introduced to compute the 18-bit authentication data 
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with CDMA cellular mobile communications system. DMDC divides messages into blocks 
of 64 bits. The DMDC hash function generates message digests with variable sizes — 18, 
32, 64 or 128 bits. This scheme is appropriate for the use of digital signatures and hence 
it can be employed to increase Internet security. 

The message to be signed is first divided into a sequence of 64-bit blocks: 


M, M2,..., M; 


Appropriate padding rules need to be devised for messages that do not divide conveniently. 
The adjacent message blocks are hashed together with a self-generated key. A better 
approach is to use one block (64 bits) of the correct message length as the key. 

Figure 4.1 shows a typical scheme for hash code computation for M = 192 bits using 
DMDC. 


4.1.1 Key Schedule 


One authentication problem in the CDMA mobile system is how to confirm the iden- 
tity of the mobile station by exchanging information between a mobile station and base 
station. When the authentication field of the access parameters message is set to ‘O01’, 
the mobile station attempts to register by sending a registration request message on 
the access channel; and the authentication procedure will be performed. Computing the 
authentication data of mobile station registrations, it is necessary to have a 152-bit mes- 
sage value which complies with RAND (32 bits), ESN (32 bits), MIN (24 bits) and 
SSD-A (64bits): 


RAND: Authentication random challenge value 

ESN: Electronic serial number 

MIN: Mobile station identification number 

SSD-A: Shared secret data to support the authentication procedure. 


The 192-bit value is composed of 152-bit message length and 40-bit padding. Suppose 
M,, M> and M; are decompositions of a 192-bit padded message. M, = 64 bits will 
be used as input to the key generation scheme in Figure 4.1. The Permuted Choice 
2 operation will produce the 48-bit key that is arranged into a 6 x 8 array as shown 
below: 


Input (column by column) 


7 13 19 25 31 37 43 
8 14 20 26 32 38 44 
9 15 21 27 33 39 45 
16 22 28 34 40 46 
11 17 23 29 35 41 47 
12 18 24 30 36 42 48 


NNnBWN Re 
= 
oO 
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M = 192 bits 
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| v v 
M = 64 bits M = 64 bits M = 64 bits 
DSS ee eer ROS Se, Pe ES CaN hee ee fy 
Y Y 
PC-1 (56 bits) IP IP 
Co= 28 bits| | Do = 28 bits L, = 32 bits R, = 32 bits L, = 32 bits R, = 32 bits 
v v | v v v 
<<< | <<< | :|E(L) = 48 bits] |E(L,) = 48 bits E(L,) = 48 bits] |E(L,) = 48 bits 
i v v H ie 
Cy D, ' 4 
: : = O 
. 1 K, 
PC-2 (48 bits) { gle ear wan 
RWP K 
1 -—4—}>| <<<2 +h 
-——_ 1 
Bees soe eee 7 
ac, 
K=48 bits 
Key v v v v 
seneraiin Tl, =E(L,)@K,| |T,=E(R)@K,| |3=EZ,)®K; | |Ty=E(R)@K, 
scheme | 
v v v 
(S-box), (S-box)5 | (S-box)3 (S-box)4 
Vv v J v 
Q, (32 bits) Q, (32 bits) | Q, (32 bits) Q, (32 bits) 
vy v | v 
PC: Permuted choice P(Q,) (32 bits) P(Q,) (32 bits)} | P(Q3) (32 bits) P(Q4) (32 bits) 
ade . Y | 
IP: Initial permutation alg 
RWP: Row-wise permutation © i 
CWP: Column-wise permutation Vv Vv 
: Concatenation <<<5 <<< 10 
HH: Addition of 32-bit integers >! | | 
module 2° 
@®: Multiplication of 32-bit integers 


module 2°? + 1 


Figure 4.1 


Message digest (64 bits) 


DMDC algorithm for M = 192 bits. 
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Row-wise permutation 

11 17 23 29 35 Al 47 
7 13 19 25 31 37 43 
9 15 21 27 33 39 45 

12 18 24 30 36 42 48 
8 14 20 26 32 38 44 

10 16 22 28 34 40 46 


BNNDWRN 


Column-wise permutation 


11 35 5 47 17 41 29 23 
7 31 1 43 13 37 25 19 
9 33 3 45 16 39 27 21 

12 36 6 48 18 42 30 24 
8 32 2 44 14 38 26 20 

10 34 4 46 16 40 28 22 


— output (row by row) 


Thus, a 48-bit key generation from M, is computed as shown in Table 4.1. 


Example 4.1 Assume that division of the 192-bit padded message into 64 bits con- 
sists of: 


M, = 7a138b2524af17c3 
M2 = 17b439a12f51c5a8 
M3 = 51cb360000000000 


Note that no one-bit flag and no message length in hex are inserted in this example. 
The 48-bit key generation using row/column permutations is given below. Assume that 


the first data block M, is used as the key input. Using Table 3.1 (PC-1), M, splits into 
two blocks: 


Co = 2481394, Do = e778253 


As shown in Table 3.2, C,; and D, are obtained from Cp and Dp by shifting one bit to 
the left, respectively. 


C, = 4902729, D, = cef04a7 


Table 4.1 A 48-bit key generation by row/column permutations 


116350 5 477 41 29 23 7 31 1 43° 13 37 .25 19 
9 33 3 45 15 39: ° -29- > 24 12 36 6 48 18 42 30 24 
8 32 2 44 14 3/8 26 20 10 34 4 46 16 40 28 22 
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Using Table 3.3 (PC-2), the 48-bit compressed key is computed as: 
Ko = 058c4517a7a2. 
Finally, using Table 4.1, the 48-bit key with the row/column permutations is computed as: 
K = 5458c42bec07 
This is the key block to be provided for Mz and M3, as shown in Example 4.2. 
Example 4.2 Referring to Figure 4.1, Mz = 17b439al12f51c5a8 and 
M3 = 51cb360000000000 are processed as follows: 

Using Table 3.4, Mz and M3 are divided into 

L, = 60275374, R, = ca9e9411 

and = Lz = 03050403, Ry = 02040206. 

Expansion of these four data blocks using Table 3.5 yields 


E(L1) = b0010eaa6bfa, E(R) = e554fd4a80a3 
and E(L2) = 80680a808006 E(R2) = 00400800400c 


The 48-bit key, K = 5458c42bcc07, obtained through row/column permutations, should 
be shifted 0, 2, 1 and 3 bits to the left such that 


K, = 5458c42bcc07 (zero shift) 

K»> = a8b18857970e (two shifts) 

K3 = 516310af301d (one shift) 

K4 = a2c6215e603a (three shifts) 

These four keys are used for XORing with expanded blocks such that 

l,; = E(Z,) @ K; = e459ca81a7fd 

Ty = E(R)) © Kz = b437ede5b0be 

13 = E(L2) ® K3 = 28d982d71808 

T4 = E(R2) ® Kg = a286295e2036 

These four T;, | < i < 4, are inputs to the (S-box);, respectively. 
Using Table 3.6, the outputs Q; of S-boxes are computed as: 

Qi = a4064766 

Qo = 1d1dabb8 

Q3 = f89d0b16 

Q4 = dabaae4d 
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Applying the operation of Table 3.7 to each Q; yields: 


P(Q1) = 00163638 
P(Q) = 9f2874d3 
P(Q3) = 96aab362 
P(Q4) = Sdf889ee 


These four data blocks resulting from Table 3.7 are used for the computation of message 
digests (or hash codes), as shown in Example 4.3. 


4.1.2 Computation of Message Digests 


Example 4.3. Compute the hash codes as follows: 
32-bit hash code computation: 


Figure 4.2 shows the processing scheme for the computation of a 32-bit hash code. In 
this figure, the following symbols are used: 


© : Multiplication of 16-bit integers modulo 2'° + 1 = 65537 
: Addition of 16-bit integers modulo 2!° = 65536 












































































































































PQ)) P(Q)) P(Q3) P(Q4) 
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X X> | re X, Z Zz 7: Zi 
& | 
Yy, TT it 
Y, rk 
c6cc ©99a fd20 ¥; @) = 
4839 
~P«—_] 
H H. 
: > || i - 











h=(H, || A>) 
= 3becala3 








Figure 4.2 32-bit hash code computation scheme. 
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® : Bit-by-bit XORing of 16-bit subblocks 


Il ; Concatenation 


Since we have already calculated P(Q2;) in Example 4.2, the message digest of 32 bits is 
ready to be computed from Figure 4.2: 


Y, = c6cc 
Yy = €99a 
Y3 = fd20 
Y4 = 4839 
HA, = 3bec 
Hy = ala3 


Concatenation of H, with H> results in the 32-bit hash code h such that 
h = (A\||H2) = 3becala3 
64-bit hash code computation: 


Referring to Figure 4.3, the 64-bit message digest is computed as follows: 


Y; = 97a0e99a 

Y> = 371d4fc8 

H, = £41d3352 

Hy = 753£20dce 

The 64-bit hash code is thus computed as: 

h = (Hj||H>) = £41d3352753f20de 

Note that: 
© : Multiplication of 32-bit blocks modulo 2” + 1 = 4294967297 
: Addition of 32-bit blocks modulo 2°? = 4294967296 

<<< m_: Shifting m bits to the left 


18-bit hash code computation: 


Utilising the 64-bit message digest h obtained above, the 18-bit hash code can be computed 
from the decimation process as shown in Figure 4.4. 


h = £41d3352753f20dc (64 bits) 
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Y5 
97a0e99a 371d4fc8 
<<< 5 | <<< 10 
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h=(H, || Hp) = £41d3352753£20de 


Figure 4.3 64-bit hash code computation scheme. 


£41d3352753f20dc 





Decimation 











h=001110011101110001 


Figure 4.4 18-bit hash code computation scheme. 


Discard six bits from both ends of the 64-bit message digest h and then pick one bit every 
three bits by the rule of decimation such that 


h = 001110011101110001 (18 bits) 


128-bit hash code computation (using left shift): 


Referring to Figure 4.5, each P(Q;) is shifted m bits to the left. Then concatenating them 
will produce the 128-bit message digest: 


AH, = 7b1b1c00 
Hy = ald34e7c 
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P(Q)) PQ,) P(Q3) P(Qy) 
v v Vv v 
<<< 7 <<< 10 <<< 15 | <<< 5 
7b1b1c00 | Ay, ald34e7c | H, 59b14b55 | A; bfl13dcb | Ay 
v v v v 














h=(H, || Ho || Hy || Hy) = 7b1b1c00 ald34e7c 59b14b55 bfl 13dceb 


Figure 4.5 128-bit hash code computation using a shift left. 


A = 59b14b55 
Hyg = bf113dcb 


Thus, the 128-bit hash code will be 
h = (A, ||| -43\| Aa) 
= 7b1b1c00a1d34e7c59b14b55bf1 13dcb 


128-bit hash code computation (using inverse): 


Based on Figure 4.6, another 128-bit message digest can be computed as follows: 


X; = 006 X7 = 3638 X3 = 9f28 X4 =74d3 
x7! = 9b24 —X> = c9c8 —X3 = 60d8 X7' = 8el2 
Z,; = 96aa Z>. = b362 Z3 = 5df8 Z4 = 89ee 
Z,| = bf34 —Z, = 4c9e —Z; = a208 Zp = 652 


Thus, the 128-bit hash code is computed from the concatenation of inverse values: 
h = (Xp ill — Xall — XsXq Zyl — Zall — ZsilZz) 
= 9d24c9c860d88e 1 2bf344c9ea208b652 


128-bit hash code computation (using addition and multiplication): 


Taking a look at Figure 4.7, computation for the 128-bit message digest proceeds as 
follows: 


P(Q1) FA P(Q3) = 97a0e99a <<< 5 = £41d3352 
P(Q2) OP(Qy) = 371d4fc8 <<< 10 = 753f20de 
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P(Q,) P(Qy) P(Q3) P(Q4) 
| | | | 
Vv Vv Vv Vv Vv Vv v Vv 
xX X, X; X, Z Z Zs LZ, 
y00fe | 3638 4 9f28 Yb 74a3 4 96aa Y b362 4 5df8 | 89ee 
xj! -X, -X; X;! Z;! -Z, -Z, Zj! 
$9424 c9e8 60d8 | 8e12 bf34 4c9e a208 b652 











9d24c9c8 60d88e12 bf344c9e a208b652 


Figure 4.6 128 -bit hash code computation using inverse operation. 


97a0e99a 


P(Q,) P(Q2) P(Q3) P(Q4) 
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371d4fc8 L_4) sc 
56c9017f fd20fec1 
<<< 5 <<<10 <<<10 <<<5 
v v v v 














f41d3352 753f20de a4lfd83f 2405fd5b 
128-bit hash code 


Figure 4.7 128 -bit hash code computation using addition and multiplication. 


P(Q1)@P(Q3) = 56c9017F <<< 10 = 2405fd5b 
P(Q2) FH P(Q4) = fd20fecl <<< 5 = adlfd83f 
h = (P(Q1) HE] P(Q3)) <<< 5||(P(Q2) OP(Q4)) <<< 10| 

















(P(Qz) LE} P(Q4)) <<< 5||(P(Q2) OP(Q3)) <<< 10 
= £41d3352 753f20dc a41fd83f 2405fd5b(128bits) 
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<<< 1 ' 
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Oorl 
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S 


LSB : Least significant bit of input value 
@ : Exclusive OR 
®): multiplication 
Px : 32-bit constant (ex. OxOOO000AE) 


Figure 4.8 State transition function F(r) for PRBS generation. 


This is the 128-bit hash code found. So far, we have discussed computation for the DMDC 
without appending a one-bit flag and the message length in hex digits. 


4.2 Advanced DMDC Algorithm 


This section presents the secure DMDC algorithm for providing an acceptable level 
of security. 


4.2.1 Key Schedule 


Figure 4.10 shows the newly devised key generation scheme. The 64-bit input key reshapes 
to the 56-bit key sequence through Table 3.1 (PC-1). The 56-bit keys are loaded into two 
28-bit registers (Co, Do). The contents of these two registers are shifted by the S} and SR 
positions to the left. S’ and S® are generated by the state transition function F(r) shown 
in Figures 4.8 and 4.10. In Figure 4.10, the 64-bit input key is separated into two 32 bits. 
Each becomes the input S;, to F(r). st and s® are computed from S,,, (mod 23). LFSR in 
Figure 4.9 is the device for the generation of a pseudo-random binary sequence (PRBS), 
whose characteristic function is: 


f(x) = x? 4474254474744 +41 Of a period 2” —1 


The 64-bit input key is assumed to be 7a138b2524afl7c5. Using Figure 4.11, entire round 
keys are computed, as shown in Table 4.2. 


134 


INTERNET SECURITY 

















Dd, Dy 


















































D7}>) Dg PF Do... 





























Figure 4.9 LFSR with the primitive polynomial f(x) = 1 + x +. x? +.x3 +.2° + x74 x for PRBS 


generation. 
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v 
Repeat for all message sub-blocks 


F(r): PRBS state change function 
mod 23: modulo 23 
PC-1: Permuted choice | 


PC-2*: Permuted choice 2 and row/column wise permutation 


<<<: Circular left shift 
||: Concatenation 


Figure 4.10 The newly devised DMDC key generation scheme. 
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Figure 4.11 New DMDC algorithm for message digest. 
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Table 4.2 Round key generation corresponding to (SP, S®) 


rth round (SE, SR) K,(rth round key) 
1 (2, 21) 36320340397a 
2 (14, 19) 9394d0aac24c 
3 (0, 15) 91c2c6fcd0le 
4 (7, 7) fcf6701c06a4 
5 (21, 13) c38496e8c45e 
6 (1, 20) 12f64d47235d 
7 (7, 17) 174a16a3c335 
332 (21, 2) 17320b413872 
333 (19, 17) 9ad8226cd646 
334 di, 11) 961203c1315b 
335 (2, 18) 125ec46f8a55 
336 (2, 13) cd8d4610f0c4 
337 (19, 9) 5e40db05 1358 
338 (15, 8) 0414fc86b547 


4.2.2 Computation of Message Digests 


After the input message M of arbitrary length appends padding, divide the padded message 
into the integer multiple of 128 bits such that M,, Mo,..., Mz ,. Each M; again positions 
to four 32-bit words as: 


Mio, Mi, Mj2, M13, M29, M21, Mo, Mp3, ..., Mzo, Mr, Mr2, M73 


where M,. = (M,o, M,1, M;2, M;3) represents the rth round 128-bit message unit as shown 
in Figure 4.11. A, B, C and D denote the four 32-bit buffers in which the data computed 
at the (r — 1)th round is to be stored. Thus, M,o @ A, M,; ®B, Mp2 @C and M,3 @D 
will become the rth round input data. Notice that the output at each round is swapped 
such that the data diffusion becomes very effective. 

The following example demonstrates motivation, so that the reader can understand the 
whole process at each round (Figure 4.11). The ASCII file structure for the input message 
is assumed to be as shown below: 


001: 12345678901234567890 
002: 23456789012345678901 
003: 34567890123456789012 


198: 89012345678901234567 
199: 90123456789012345678 
200: 01234567890123456789 


After receiving this ASCII file as input, the 128-bit divided blocks are expressed in 
hexadecimal notation as follows: 
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3030313a 20313233 
32333435 36373839 
32333435 36373839 
3a203031 32333435 
34353637 38398000 


34353637 
300d0a30 
30313233 


36373839 
00000000 


38393031 
30323a20 
34353637 


30313233 
0000a8b0 
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In the last block, the last three words contain padding and message length. The message 
length is Oxa8b0(43184 in decimal). 
The swapped outputs A, B, C and D at each round are computed as shown in 


Table 4.3. 


Thus, the hash code computations applied to the new DMDC algorithm are listed in 


Table 4.4. 


The DMDC algorithm is a secure, compact and simple hash function. The security of 
DMDC has never been mathematically proven, but it depends on the problem of F(r) 
generating the PRBS sequence which makes each 28-bit key (left and right) shift to the 


Table 4.3. The swapped output A, B, C and D at each round 


Round 


NNBWNE 


333 
334 
335 
336 
337 
338 


A 


3b1b9ba3 
f51e7b49 
06b402c3 
c549ff13b 
68433a67 
9e53f8b6 


Ob4cbc7b 
36aelc4b 

c530fa5f 
487df0b3 
58804c4c 
eeOfd67d 


B 


d126ddbe 
867a615d 
a6fd207f 
bceaa5a7 
94f78e05 
5d6b7335 


Sabebd16 
03b94506 
£48260b2 
e046c2c9 
223ee9ae 
fdaOda6a 


Cc 


bd3a26d1 
b2990b90 
256bdeb5 
Odlicee9e 
7c72e14f 
457465 le 


ccae2d5b 
89304464 

1f8e5c7f 
999e1066 
fd265d3a 
df5c7095 


D 


67cfbOf3 
d49538dd 
efdd2572 
a335cf90 
a32eae10 
9b1b6489 


b50606d1 
28457cce 
814a2152 
f27ba5d3 
7894aa4c 
94287b6c 


Table 4.4 Hash code values based on the new DMDC scheme 


Hash code length 


128 bits 


32 bits 

64 bits 

18 bits 
using left shift 
using inverse 


using addition and 


O7eb3ef78369abf6384aefae850f6d92 
ad88e2594fe4287a392abad2 13122695 


10c62983026032634cdc8f6b6bd84085 
multiplication 


Hash value 


5f£79ee7e 
ad88e2594fe4287a 
32064 
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left. The secure DMDC processes data sequentially block-by-block of a 128-bit unit when 
computing the message digest. The computation uses four working registers labelled A, 
B, C and D. These register contents are the swapped outputs at the end of each round. 
The four 32-bit input unit are XORed with the register contents. This process offers good 
performance and considerable flexibility. 


4.3 MD5 Message-digest Algorithm 


The MDS5 message-digest algorithm was developed by Ronald Rivest at MIT in 1992. 
This algorithm takes a input message of arbitrary length and produces a 128-bit hash 
value of the message. The input message is processed in 512-bit blocks which can be 
divided into 16 32-bit subblocks. The message digest is a set of four 32-bit blocks, which 
concatenate to form a single 128-bit hash code. MD5 (1992) is an improved version of 
MD4, but is slightly slower than MD4 (1990). 

The following steps are carried out to compute the message digest of the input message. 


4.3.1 Append Padding Bits 


The message is padded so that its length (in bits) is congruent to 448 modulo 512. That 
is, the padded message is just 64 bits short of being a multiple of 512. This padding 
is formed by appending a single ‘ 1’ bit to the end of the message, and then ‘ 0’ bits 
are appended as needed such that the length (in bits) of the padded message becomes 
congruent to 448 (= 512 — 64), modulo 512. 


4.3.2 Append Length 


A 64-bit representation of the original message length is appended to the result of the 
previous step. If the original length is greater than 2°, then only the low-order 64 bits of 
the length are used for appending two 32-bit words. 

The length of the resulting message is an exact multiple of 512 bits. Equivalently, this 
message has a length that is an exact multiple of 16 (32-bit) words. Let M[O...N — 1] 
denote the word of the resulting message, with N an integer multiple of 16. 


4.3.3 Initialise MD Buffer 


A four-word buffer represents four 32-bit registers (A, B, C and D). This 128-bit buffer 
is used to compute the message digest. These registers are initialised to the following 
values in hexadecimal (low-order bytes first): 


A = 01 23 45 67 
B = 89 ab cd ef 
C = fe dc ba 98 
D = 76 54 32 10 
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These four variables are then copied into different variables: A as AA, B as BB, C as CC 
and D as DD. 


4.3.4 Define Four Auxiliary Functions (F, G, H, I) 


F, G, H and IJ are four basic MDS5 functions. Each of these four nonlinear functions takes 
three 32-bit words as input and produces one 32-bit word as output. They are, one for 
each round, expressed as: 


F(X, Y, Z) = (X-Y) + (KZ) 

G(X, Y, Z) = (X-Z) + (Y-Z) 

H(X, Y,Z)=X@YOZ 

W(X, Y,2=Y@(X+ZD 

where X-Y denotes the bitwise AND of X and Y; X+ Y denotes the bitwise OR of X 


and Y; X denotes the bitwise complement of X, ie. NOT(X); and X @ Y denotes the 
bitwise XOR of X and Y. 

These four nonlinear functions are designed in such a way that if the bits of X, Y 
and Z are independent and unbiased, then at each bit position the function F acts as a 
conditional: if X then Y else Z. The functions G, H and I are similar to the function F 
in that they act in ‘bitwise parallel’ to their product from the bits of X, Y and Z. Notice 
that the function H is the bitwise XOR function of its inputs. 

The truth table for the computation of four nonlinear functions (F, G, H, I) is given in 
Table 4.5. 


4.3.5 FF, GG, HH and Il Transformations for Rounds 1, 2, 3 and 4 


If M[k], 0 < k < 15, denotes the kth sub-block of the message, and <<< s represents a 
left shift s bits, the four operations are defined as follows: 


FF(a, b, c, d, M[A], s,i):a=b+((a+ FO, c, d) + M[k] + T[i] <<< s) 
GG a, b, c, d, M[k],s,7):a=b+ ((a+ Gib, c, d) + M[k] + T[i] <<< s) 


Table 4.5 Truth table of 
four nonlinear functions 


XYZ FGHI 


000 0001 
001 1010 
010 0110 
O11 1001 
100 0011 
101 0101 
110 1100 


111 1110 
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HH(a, b, c, d, M[K],s, i): a=b+((a+ H(b, c, d) + M[k] + T[i] <<< s) 
II(a, b, c, d, MIK], s,i):a=b+ ((a+I(b, c, d) + M[k] + Ti] <<< s) 


Computation uses a 64-element table T[i], i = 1,2, ..., 64, which is constructed from the 
sine function. T[i] denotes the ith element of the table, which is equal to the integer part 
of 4294967296 times abs(sin(i)), where i is in radians: 


T[i] = integer part of [2°? « |sin(i)|] 


where 0 < |sin(i)| < 1 and 0 < 2” x |sin(i)| < 2°. 
Computation of T[i] for 1 <i < 64 is shown in Table 4.6. 


4.3.6 Computation of Four Rounds (64 Steps) 


Each round consists of 16 operations. Each operation performs a nonlinear function on 
three of A, B, C and D. Let us show FF, GG, HH and II transformations for rounds 1, 2, 
3 and 4 in what follows. 


Round 1 


Let FF[a, b, c, d, M[K], s, i] denote the operation 


a=b+((a+F(b, c, d) + M[k] + Tli]) <<<s). 


Then the following 16 operations are computed: 


FF[a, b, c, d, M[O], 7, 1], FF[d, a, b, c, M[1], 12, 2], FF[c, d, a, b, M[2], 17, 3], 
FF[b, c, d, a, M[3], 22, 4], FF[a, b, c, d, M[4], 7, 5], FF[d, a, b, c, M[5], 12, 6], 


Table 4.6 Computation of T[i] For 1 <i < 64 


T[1] = d76aa478 
T[2] = e8c7b756 
T[3] = 242070db 
T[4] = clbdceee 
T[5] = £57cOfaf 

T[6] = 4787c62a 
T[7] a8304613 
T[8] fd469501 
T[9] = 698098d8 
T[10] = 8b44f7af 
T[11] = ffff5bb1 

T[12] = 895cd7be 
T[13] = 66901122 
T[14] = £d987193 
T[15] = a679438e 
T[16] = 49b40821 


T[17] = f61e2562 
T[18] = c040b340 
T[19] = 265e5a51 
T[20] = e9b6c7aa 
T[21] = d62f105d 
T[22] = 02441453 
T[23] = d8ale681 
T[24] = e7d3fbc8 
T[25] = 2lelcde6 
T[26] = c33707d6 
T[27] = £4d50d87 
T[28] = 455al4ed 
T[29] = a9e3e905 
T[30] = fcefa3f8 

T[31] = 676f02d9 
T[32] = 8d2a4c8a 


T[33] = fffa3942 

T[34] = 8771f681 
T[35] = 69d96122 
T[36] = fde5380c 
T[37] = a4beea44 
T[38] = 4bdecfa9 

T[39] = f6bb4b60 
T[40] = bebfbc70 
T[41] = 289b7ec6 
T[42] = eaal27fa 

T[43] = d4ef3085 
T[44] = 04881d05 
T[45] = d9d4d039 
T[46] = e6db99e5 
T[47] = 1fa27cf8 

T[48] = c4ac5665 


T[49] = £4292244 
T[50] = 432aff97 
T[51] = ab9423a7 
T[52] = fc93a039 
T[53] = 655b59c3 
T[54] = 8f0ccc92 
T[55] = ffeff47d 

T[56] = 85845dd1 
T[57] = 6fa87e4f 
T[58] = fe2ce6e0 
T[59] = a3014314 
T[60] = 4e081 lal 
T[61] = £7537e82 
T[62] = bd3af235 
T[63] = 2ad7d2bb 
T[64] = eb86d391 
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a=b+((atF(b, c, d) + M[k] + TIil) <<< s) 








Figure 4.12 Basic MDS operation. 


FF[c, d, a, b, M[6], 17, 7], FF[b, c, d, a, MI7], 22, 8], FF[a, b, c, d, M[8], 7, 9], 

FF[d, a, b, c, M[9], 12, 10], FF[c, d, a, b, M[10], 17, 11], FF[b, c, d, a, M[11], 22, 12], 
FF[a, b, c, d, M[12], 7, 13], FF[d, a, b, c, M[13], 12, 14], FF[c, d, a, b, M[14], 17, 15], 
FF[b, c, d, a, M[15], 22, 16] 


The basic MD5 operation for FF transformations of round 1 is plotted as shown in 
Figure 4.12. GG, HH and II transformations for rounds 2, 3 and 4 are similarly sketched. 
Round 2 

Let GG[a, b, c, d, M[k], s, i] denote the operation 

a=b+((a+G(b, c, d) + M[k] + TLi]) <<<s). 

Then the following 16 operations are computed: 


GG[a, b, c, d, M[1], 5, 17], GG[d, a, b, c, M[6], 9, 18], GG[c, d, a, b, M11], 14, 19], 
GGIb, c, d, a, M[O], 20, 20], GG[a, b, c, d, MIS], 5, 21], GG[d, a, b, c, M[10], 9, 22], 
GG[c, d, a, b, M[15], 14, 23], GG[b, c, d, a, M[4], 20, 24], GGTa, b, c, d, M[9], 5, 25], 
GG[d, a, b, c, M[14], 9, 26], GG[c, d, a, b, M[3], 14, 27], GG[b, c, d, a, M[8], 20, 28], 
GG[a, b, c, d, M[13], 5, 29], GG[d, a, b, c, M[2], 9, 30], GG[c, d, a, b, M[7], 14, 31], 
GGIb, c, d, a, M[12], 20, 32], 


Round 3 

Let HH[a, b, c, d, M[K], s, i] denote the operation 
a=b+((a+H(b, c, d) + M[k] + T[i]) <<<s). 
Then the following 16 operations are computed: 


HH[a, b, c, d, M[5], 4, 33], HH[d, a, b, c, M[8], 11, 34], HH[c, d, a, b, M[11], 16, 35], 
HH[b, c, d, a, M[14], 23, 36], HH[a, b, c, d, M[1], 4, 37], HH[d, a, b, c, M[4], 11, 38], 
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HH[c, d, a, b, M[7], 16, 39], HHIb, c, d, a, M[10], 23, 40], HH[a, b, c, d, M[13], 4, 41], 
HH[d, a, b, c, M[O], 11, 42], HH[c, d, a, b, M[3], 16, 43], HH[b, c, d, a, M[6], 23, 441, 
HHf[a, b, c, d, M[9], 4, 45], HH[d, a, b, c, M[12], 11, 46], HH[c, d, a, b, M[15], 16, 47], 
HHIb, c, d, a, M[2], 23, 48], 


Round 4 

Let II[a, b, c, d, M[K], s, i] denote the operation 
a=b+ ((a+I(b, c, d) + M[k] + Tli]) <<<s). 
Then the following 16 operations are computed: 


Il[a, b, c, d, M[0], 6, 49], I[d, a, b, c, MI7], 10, 50], Ufc, d, a, b, M[14], 15, 51], 
Il[b, c, d, a, M[5], 21, 52], Ifa, b, c, d, M[12], 6, 53], Il[d, a, b, c, M[3], 10, 54], 
I[c, d, a, b, M[10], 15, 55], II[b, c, d, a, M[1], 21, 56], Ila, b, c, d, MIS], 6, 57], 
Il[d, a, b, c, M[15], 10, 58], II[c, d, a, b, M[6], 15, 59], II[b, c, d, a, M[13], 21, 60], 
Il[a, b, c, d, M[4], 6, 61], I[d, a, b, c, M[11], 10, 62], I[c, d, a, b, M[2], 15, 63], 
II[b, c, d, a, M[9], 21, 64], 


After all of the above steps, A, B, C and D are added to their respective increments AA, 
BB, CC and DD, as follows: 


A=A+AA,B=B+BB 
C=C+CC, D=D+DD 


and the algorithm continues with the resulting block of data. The final output is the 
concatenation of A, B, C and D. 


Example 4.4 The message digest problem related to the CDMA cellular system will 
be discussed in this example. 
Set the initial buffer contents as follows: 


A = 67452301 B = efcdab89 
C = 98badcfe D = 10325476 


The 512-bit padded message is produced from the 152-bit CDMA message by appending 
the 360-bit padding as shown below. 
Padded message (512bits) = Original message(152bits) + Padding (360bits): 


7al38b25 24afl7c3 17b439al 2f51c5a8 
805 1cb36 00000000 00000000 00000000 
00000000 00000000 00000000 00000000 
00000000 00000000 00000098 00000000 


I. Round | Computation for FF[a, b, c, d, M[K], s, i] a= b+ ((a+ F(b, c, d) + M[k] + 
Tli]) <<<s)=b+U <<<s,0<k < 15,1 <i < 16 where U <<<s denotes the 32- 
bit value obtained by circularly shifting U left by s bit positions. 
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(1) First-word block process (M[0], T[1], s = 7) 
Using Table 4.5, F(b, c, d) is computed as shown below: 


b: 1110 1111 1100 1101 1010 1011 1000 1001 


c: 1001 1000 1011 1010 1101 1100 1111 1110 
d: 0001 0000 =: 0011 0010 0101 0100 = O111 0110 


F(b, c, d): 1001 1000 1011 1010 1101 1100 1111 1110 
9 8 b a d c f e 
Compute U = (a+ F(b, c, d) + M[0] + T[1]) <<<s,s=7 
a: 67452301 


F(b, c, d): 98badcfe 
M[0]: 7a138b25 
T[1]: d76aa478 


U: 517e2f9c 


U' = 517e2 f9c <<<7 
= (0101 0001 0111 1110 00410 1111 1001 1100) <<<7 


Since U <<<7 denotes the circular shift of U to the left by 7 bits, the shifted U 
value yields: 


U’: 1011 1111 0001 0111 1100 1110 =0010 1000 


b f 1 7 c e 2 8 
From a=b+U’, we have 
b: efcdab89 
U’: bf17ce28 
a: aee579b 1 


Hence, FF[a, b, c, d, M(0), 7, 1] of NO.1 operation can be computed as aee579b1, 
efcdab89, 98badcfe, 10325476. 
(2) Second-word block process (M[1], T[2], s = 12) 

Using the outcome from operation (1), the second-word block is processed as follows: 


d: 10325476 

F[a, b, c]: bedfadcf 
M[1]: 24af17c3 
T[2]: e8c7b756 


U: dc88d15e 
U' =U «<<< 12: 8d15edc8 
From d=a+U’, we have 

a: aee57961 


U’: 8d15edc8 
d: 3bfb6779 
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Hence, the result of operation (2) for the second-word block becomes FF[d, a, b, c, M[1], 
12, 2] = (aee57961, efcdab89, 98badcfe, 3bfb6779). 

All FF transformations for Round | are similarly computed, and consist of the following 
results from the 16 operations: 


[1] aee57961 efcdab89 98badcfe 10325476 
[2] aee57961 efcdab89 98badcfe 3bfb6779 
[3] aee57961 efcdab89 1e52ee63 3bfb6779 
[4] aee57961 2279e391 1e52ee63 3bfb6779 
[5] 65976331 2279e391 1e52ee63 3bfb6779 
[6] 65976331 2279e391 1e52ee63 b766cf0e 
[7] 65976331 2279e391 e776a653 b766cf0e 
[8] 65976331 d4a89062 e776a653 b766cf0e 
[9] 140e3c3d d4a89062 e776a653 b766cf0e 
[10] 140e3c3d d4a89062 e776a653 59a02fdf 
[11] 140e3c3d d4a89062 d62326dc 59a02fdf 
[12] 140e3c3d 9d8eb345 d62326dc 59a02fdf 
[13] 7dccdlee 9d8eb345 d62326dc 59a02fdf 
[14] 7dccdlee 9d8eb345 d62326dc 0359415c 
[15] 7dccdlee 9d8eb345 bff77632 0359415c 
[16] 7dccdlee 10821d51 bff77632 0359415c 


II. Round 2 Computation for GG 
(1) First-word block operation: 


a=b+((at+ Gib, c, d) + M[1] + TLI7]) <<<s) 


Let V=a+ Gib, c, d) + M[1] + T[17] where a = 7dccdlee, b = 10821d51, 
c = bff77632, d = 0359415c, 


M[1] = 24af17c3, and T[17] = f61e2562. 
Using Table 4.5, G(b, c, d) is computed as follows: 


b: 0001 0000 1000 0010 0001 1101 0101 0001 
C: 1011 1111 1111 Oll1 Ol11 O110 0011 0010 
d: 0000 0011 O10! 1001 0100 0001 0101 1100 


Gib, c, d): 1011 1100 1010 0110 0011 0111 0111 0010 
b c a 6 3 7 7 2 


Compute V = a+ Gib, c, d) + M[1] + T[17] 


a: 7dccdlee 

Gib, c, d): bea63772 
M[1]: 24af17c3 
T[17]: f61e2562 


V: 55404685 


HASH FUNCTION, MESSAGE DIGEST AND HMAC 


V: 0101 0101 0100 0000 0100 0110 1000 0101 


Since V’ = V <<<5, V’ becomes 
v’ = 1010 1000 0000 1000 1101 0000 1010 
a 8 0 8 d 0 a 
From a= b+ V’, we have 
b: 10821d51 
V’: a808d0aa 
a: b88aedfb 


Thus, GG[a, b, c, d, M[1], T[17], 5] of operation (1) is computed as: 


b88aedfb, 10821d51, bff77632, 0359415c 
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1010 


a 


Through the 16 operations, GG transformation for round 2 can be accomplished as 


shown below: 


[1] b88aedfb 
[2] b88aedfb 
[3] b88aedfb 
[4] b88aedfb 
[5] 80426a6a 
[6] 80426a6a 
[7] 80426a6a 
[8] 80426a6a 
[9] cbec5d78 
[10] cbec5d78 
[11] cbec5d78 
[12] cbec5d78 
[13] Sb8a2ae8 
[14] 5b8a2ae8 
[15] S5b8a2ae8 
[16] Sb8a2ae8 


a 


II. Round 3 Computation for HH 


(1) First-word block operation: 


10821d51 
10821d51 
10821d51 
6b6c164c 
6b6c164c 
6b6c164c 
6b6c164c 
719elda6 
719elda6 
719elda6 
719elda6 
167849a5 
167849a5 
167849a5 
167849a5 
29e29554 


bff77632 

bff77632 

20aeb48b 
20aeb48b 
20aeb48b 
20aeb48b 
f0263bced 
f0263bced 
f0263bed 
f0263bced 
a05494c9 
a05494c9 
a05494c9 
a05494c9 
2e6d799d 
2e6d799d 


a= b+ ((a+ H(b, c, d) + M[5] + T[33]) <<< 4) 


0359415c 
f14f0cf3 
f14f0cf3 
f14f0cf3 
f14f0cf3 
2ac992e7 
2ac992e7 
2ac992e7 
2ac992e7 
455ddcd7 
455ddcd7 
455ddcd7 
455ddcd7 
af92e3c8 
af92e3c8 
af92e3c8 


where a = 5b8a2ae8, b = 29e29554, c = 2e6d799d, d = af92e3c8, M[5] = 00000000, 
T[33] = fffa3942, and s = 4. 
Using Table 4.5, H(b, c, d) is computed as follows: 


b: 
Cc: 
d: 


1001 
0111 
1110 


0100 
1101 
1000 


H(b, c, d): 


0010 1001 
0010 1110 
1010 1111 
1010 1000 
a 8 


1110 0010 

0110 1101 

1001 0010 

0001 1101 
1 d 


0000 
0 


0101 0101 
1001 1001 
0011 1100 
1111 0000 
f 0 


0001 
1 


146 INTERNET SECURITY 


Compute W = a+ H(b, c, d) + M[5] + T[33] 


a: S5b8a2ae8 

H(b, c, d): a81d0f01 
M[5]: O0000000 
T[33]: fffa3942 


W: 03a1732b 


W = 0000 0011 1010 0001 0111 0011 0010 1011 
Since W’ = W <<< 4, we have 


W’ = 0011 1010 0001 = Ol111 0011 0010 1011 0000 
3 a 1 7 3 2 b 0 


From a = b + W’, a can be computed as 


b: 29e29554 
W’: 3a1732b0 


a: 63f9c804 


Thus, HH[a, b, c, d, M[5], T[33], 4] of operation (1) is obtained as 63f9c804 29e29554 
2e6d799d af92e3c8. Through 16 operations, HH transformation for round 3 can be com- 
puted as shown below: 


[1] 63f£9c804 29e29554 2e6d799d af92e3c8 
[2] 63f£9c804 29e29554 2e6d799d 3bf27cdf 
[3] 63f£9c804 29e29554 38408ad2 3bf27cdf 
[4] 63f£9c804 39049458 38408ad2 3bf27cdf 
[5] bae75a5e 39049458 38408ad2 3bf27cdf 
[6] bae75a5e 39049458 38408ad2 edcbf07c 
[7] bae75a5e 39049458 02788da0 edcbf07c 
[8] bae75a5e 279f19dc 02788da0 edcbf07c 
[9] e292ec26 279f19dc 02788da0 edcbf07c 
[10] e292ec26 279f19dc 02788da0 937294f5 
[11] e292ec26 279f19dc 784ef22d 9372945 
[12] e292ec26 67e9dd0d 784ef22d 9372945 
[13] fbc16051 67e9dd0d 784ef22d 9372945 
[14] fbc16051 67e9dd0d 784ef22d 9fb3bb46 
[15] fbc16051 67e9dd0d 14f356d2 9fb3bb46 
[16] fbc16051 814dbecf 14f356d2 9fb3bb46 


IV. Round 4 Computation for II 
(1) First-word block operation: 


a=b+((a+I(b, c, d) + M[0] + T[49]) <<< 6) 


where a = fbc16051, b = 814dbccf, c = 14f356d2, d = 9fb3bb46, M[0] = 7a138b25, 
T[49] = £4292244, and s = 6. 
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Using Table 4.5, I(b, c, d) can be computed as follows: 


b: 1000 = 0001 0100 1101 1011 1100 
c: 0001 0100 1111 0011 0101 0110 


1100 
1101 


d: 1001 1111 1011 0011 1011 1011 0100 
I(b, c, d): 1111 0101 1011 1110 1010 1010 0010 


f 5 b e a a 
Compute Z = a+ I(b, c, d) + M[O] + T[49] 


a: fbc16051 

I(b, c, d): f5beaa2d 
M[O]: 7a138b25 
T[49]: £4292244 


Z : 5focb7e7 


Z = 0101 1111 1011 1100 1011 0111 1110 0111 
Since Z’ = Z <<< 6, we have 


Z' = 1110 1111 0010 1101 1111 1001 1101 
e f 2 d f 9 d 


From a = b+ Z’, a is computed as: 


b: 814dbecf 
Z’: ef2df9d7 


a: 707bb6a6 
Thus, operation (1) of II[a, b, c, d, M[0], T[49], 6] is obtained as: 
707bb6a6 814dbecf 14f356d2 9fb3bb46 


The results from 16 operations are listed in the following: 


[1] 707bb6a6 814dbecf 14f356d2 9fb3bb46 
[2] 707bb6a6 814dbecf 14f356d2 b374acla 
[3] 707bb6a6 814dbecf 1dcb5424 b374acla 
[4] 707bb6a6 ebc0a7cd 1dcb5424 b374acla 
[5] eladb47e ebc0a7cd 1dcb5424 b374acla 
[6] eladb47e ebc0a7cd 1dcb5424 2307ce67 
[7] eladb47e ebc0a7cd fc5d488d 2307ce67 
[8] eladb47e 65cbb221 fc5d488d 2307ce67 
[9] 25173275 65cbb221 fc5d488d 2307ce67 
[10] 25173275 65cbb221 fc5d488d e801a803 
[11] 25173275 65cbb221 9da76743 e801a803 
[12] 25173275 Of04df84 9da76743 e801a803 
[13] d4921a8b Of04df84 9da76743 e801a803 
[14] d4921a8b Of04df84 9da76743 400fe907 


147 


1111 
0010 
0110 


1101 
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[15] d4921a8b Of04df84 £3d96b57 400fe907 
[16] d4921a8b 24903b0e £3d96b57 400fe907 


A buffer containing four 32-bit registers A, B, C and D is used to compute the 128-bit 
message digest. These registers are initialised to the following values: 


aa = 67452301, bb = efcdab89 
cc = 98badcfe, dd = 10325476 


The last operation of this transformation is: 


a= d4921a8b, b= 24903b0e 
c = £3d96b57, d= 400fe907 


After this, the following additions are finally performed to produce the message digest. 


A=a-+aa 
B=b+bb 
C=c+cc 
D=d+dd 


The message digest produced as an output of A, B, C and D is the concatenation of A, 
B, C and D. 


a: d4921a8b b: 24903b0e 
aa: 67452301 bb: efcdab89 
A: 3bd73d8c B: 145de697 
c: £3d96b57 d: 400fe907 
cc: 98badcfe dd: 10325476 
C: 8c944855 D: 50423d7d 


The concatenation of the four outputs of A, B, C and D is the 128-bit message digest 
such that Aj] B|| Cj] D = 3bd73d8c 145de697 8c944855 50423d7d 


In CDMA cellular mobile communications, a shared secret data (SSD) is a 128-bit 
pattern stored in semi-permanent memory in the mobile station. SSD is partitioned into two 
64-bit distinct subsets, SSD-A and SSD-B. SSD-A is used to support the authentication 
process, while SSD-B is used to support voice privacy and message confidentiality. 

SSD data subsets are generated from the message digest as follows: 


SSD-A: 3bd73d8c145de697, 
SSD-B: 8c94485550423d7d. 
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4.4 Secure Hash Algorithm (SHA-1) 


The Secure Hash Algorithm (SHA) was developed by the National Institute of Standards 
and Technology (NIST) for use with the Digital Signature Algorithm (DSA) and published 
as a Federal Information Processing Standards (FIPS PUB 180) in 1993. The Secure Hash 
Standard (SHS) specifies a SHA-1 for computing the hash value of a message or a data 
file. When a message of any length of less than 2™ bits is input, the SHA-1 produces 
a 160-bit output called a message digest (or a hash code). The message digest can then 
be input to the DSA, which generates or verifies the signature for the message. Signing 
the message digest rather than the message often improves the efficiency of the process 
because the message digest is usually much smaller than the message. 

The SHA-1 (FIPS 180-1, 1995) is a technical revision of SHA (FIPS 180, 1993). 
The SHA-1 is secure because it is computationally impossible to find a message which 
corresponds to a given message digest, or to find two different messages which produce 
the same message digest. Any change to a message in transit will result in a different 
message digest, and the signature will fail to verify. The SHA-1 is based on the MD4 
message digest algorithm and its design is closely modelled on that algorithm. 


4.4.1 Message Padding 


The message padding is provided to make a final padded message a multiple of 512 bits. 
The SHA-1 sequentially processes blocks of 512 bits when computing the hash value (or 
message digest) of a message or data file that is provided as input. Padding is exactly the 
same as in MDS. The following specifies how this padding is performed. As a summary, 
first append a ‘1’ followed by as many ‘0’s as necessary to make it 64 bits short of 
a multiple of 512 bits, and finally a 64-bit integer is appended to the end of the zero- 
appended message to produce a final padded message of length n x 512 bits. The 64-bit 
integer ‘I’ represents the length of the original message. Now, the padded message is then 
processed by the SHA-1 as n x 512 bit blocks. 


Example 4.5 Suppose the original message is the bit string 
01100001 01100010 01100011 


This message has length I= 24. After ‘1’ is appended, we have 01100001 01100010 
011000111. The number of bits of this bit string is 25 because I = 24. Therefore, we 
should append 423 ‘0’s and the two-word representation of 24, i.e. 00000000 00000018 
(in hexs) for forming the final padded message as follows: 


61626380 00000000 00000000 00000000 
00000000 00000000 00000000 00000000 
00000000 00000000 00000000 00000000 
00000000 00000000 00000000 00000018 


This final padded message consisting of one block contains 16 words = 16 x 8 x 4= 512 
bits for n = | in this case. 
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4.4.2 Initialise 160-bit Buffer 


The 160-bit buffer consists of five 32-bit registers (A, B, C, D and E). Before processing 
any blocks, these registers are initialised to the following hexadecimal values: 


Hy = 67 45 23 Ol 
A, = ef cd ab 89 
Hy = 98 ba dc fe 
A, = 10 32 54 76 
A, = c3 d2 el f0 


Note that the first four values are the same as those used in MDS. The only difference is 
the use of a different rule for expressing the values, i.e. high-order octets first for SHA 
and low-order octets first for MD5. 


4.4.3 Functions Used 


A sequence of logical functions fo, f,, ..., f79 is used in SHA-1. Each function f;,0 < 
t < 79, operates on three 32-bit words B, C and D, and produces a 32-bit word as output. 
Each operation performs a nonlinear operation of three of A, B, C and D, and then does 
shifting and adding as in MDS. The set of SHA primitive functions, f, (B, C, D) is defined 
as follows: 


f,(B, C, D) = (B-C)+ (B+ D),0<1< 19 

f,(B, C, D) =BOC@D,20 <tr < 39 

f,(B, C, D) = (B-C)+(B-D)+(C-D), 40 <1 < 59 
f,(B, C, D) =BOC@D,60<1<79 


where B + C = bitwise logical ‘AND’ of B and C 
B @C = bitwise logical XOR of B and C 
B = bitwise logical ‘complement’ of B 
= addition modulo 2 


As you can see, only three different functions are used. For 0 < t < 19, the function f, 
acts as a conditional: if B then C else D. For 20 < t < 39 and 60 < t < 79, the function 
f, is true if two or three of the arguments are true. Table 4.7 is a truth table of these 
functions. 


4.4.4 Constants Used 

Four distinct constants are used in SHA-1. In hexadecimal, these values are given by 
K; = 5a827999, O<t<19 

K, = 6ed9ebal, 20 <t < 39 

K,; = 8fbbcdc, 40 <t < 59 

K, =ca62cld6, 60<t<79 
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Table 4.7 Truth table of four nonlinear functions for SHA-1 


C fo.1,...,19 f50,21,...,39 £40,41,...,59 f60,61,...,79 
0 0 0 0 0 0 0 
0 0 1 1 1 0 1 
0 1 0 0 1 0 1 
0 1 1 1 0 1 0 
1 0 0 0 1 0 1 
1 0 1 0 0 1 0 
1 1 0 1 0 1 0 
1 1 1 1 1 1 1 


4.4.5 Computing the Message Digest 


The message digest is computed using the final padded message. To generate the message 
digest, the 16-word blocks (Mp to M5) are processed in order. The processing of each 
M, involves 80 steps. That is, the message block is transformed from 16 32-bit words 
(Mp to Mis) to 80 32-bit words (Wo to W79) using the following algorithm. 

Divide M; into 16 words Wo, W;,..., Wis, where Wo is the leftmost word. For t = 0 
to 15, W, = M,. For t = 16 to 79, W, = S!'(W,_16 ® W;-14 ® W;_-s ® W,_3). 

Let A= Ho, B = Hi, C = Ho, D= H, E = Hy. For t = 0 to 79 do 











TEMP = S°(A) + F,(B, C, D) +E+ W,4+ K;; 
E=D;D=C;C = S*°(B);B = A; A = TEMP 
where: 


A, B, C, D, E: Five words of the buffer 

t: Round number, 0 < t < 79 

S': Circular left shift by i bits 

W,: A 32-bit word derived from the current 512-bit input block 
K,: An additive constant 

[4]; Addition modulo 2” 


After all N 512-bit blocks have been processed, the output from the Nth stage is the 
160-bit message digest, represented by the five words Ho, H), Hy, H3 and Hy. 

The SHA-1 operation looking at the logic in each of 80 rounds of one 512-bit block 
is shown in Figure 4.13. 


Example 4.6 Show how to derive the 32-bit words W,;,0<t<79, from the 512- 
bit message. 
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t W, 

15 Wis = Mis 

16 Wis =S° (Wo ® W2 ® Ws @ Wj3) 

17 Wi7=S° (Wi © W3 @ Wo © Wig) 

30 W3) = S) (Wi4 © Wi6 @ Wa ® W7) 

31 W31 =S) (Wis © Wi7 © Wo3 ® Woe) 

59 Wso = S° (Wa3 @ Was @ Ws1 © Wso) 

60 Woo = S) (Waa © Wace @ Ws2 ® Ws7) 

78 Wg = S° (Wor ® Woa ® Wr @ Ws) 

79 Wr = S° (Wo3 ® Wos ® Wi @ Wr) 
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Figure 4.13 SHA-1 operation. 


Example 4.7 Let the original message be 1a7fd53b4c. Then, the final padded message 
consists of the following 16 words: 


la7fd53b 4c800000 00000000 00000000 
00000000 00000000 00000000 00000000 
00000000 00000000 00000000 00000000 
00000000 00000000 00000000 00000028 


The initial hex values of {H;} are 
Ho = 67452301 
H, = efcdab89 


Hy = 98badcfe 
Ay = 10325476 
Ay = c392e1f0 
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The hex values of A, B, C, D and E after pass t(0 < t < 79) are computed as follows: 


~ 


OMAANINDNNKRWNK CO 


A 


ba346dee 
f9be8ae4 

84e1fdf6 

1b82edab 
531f1a75 

926052f7 
c71cfaac 

341b3a4b 
79a59326 
d47fe3c4 
185db57b 
3569d479 
6b01c842 
5d3c5387 
04434893 
c1456f97 
a44dbea6 
ef0512e1 

£3c545ab 
b78calcc 
a3d6efd7 
c3880afc 

a25fd097 
2263e9cb 
cd820d01 
9824bad0 
59e04bced 
b7581fd3 
Tefb6e25 

18d1583d 
42659f77 
22b4bfef 
a9390191 
ffd2919f 

a0585c33 


B 


67452301 
ba346dee 
f9be8ae4 
84e1 fdf6 
1b82edab 
531f1a75 
926052f7 
c71cfaac 
341b3a4b 
79a59326 
d47fe3c4 
185db57b 
3569d479 
6b01c842 
5d3c5387 
04434893 
c1456f97 
a44dbea6 
ef0512e1 
£3c545ab 
b78calcc 
a3d6efd7 
c3880afc 
a25fd097 
2263e9cb 
cd820d01 
9824bad0 
59e04bcd 
b7581fd3 
Tefb6e25 
18d1583d 
42659f77 
22b4bfef 
a9390191 
ffd2919f 


Register output 
C 


Tbf36ae2 
59d148c0 
ae8d1b7b 
3e6fa2b9 
al387f7d 
c6e0bb6a 
54c7c69d 
e498 14bd 
31c73eab 
cd06ce92 
9e6964c9 
351ff8f1 
c6176d5e 
4d5a75le 
9ac07210 
d74f14el 
c110d224 
f0515be5 
a9136fa9 
7Tbc144b8 
fcef1516a 
2de32873 
e8f5bbf5 
30e202bf 
e897f425 
c898fa72 
73608340 
26092eb4 
5678 12f3 
edd607f4 
5fbedb89 
4634560f 
d09967dd 
c8ad2ffb 
6a4e4064 


D 


98badcfe 
Tbf36ae2 
59d148c0 
ae8d1b7b 
3e6fa2b9 
al387f7d 
c6e0bb6a 
54c7c69d 
e498 14bd 
31c73eab 
cd06ce92 
9e6964c9 
351ff8f1 
c6176d5e 
Ad5a75le 
9ac07210 
d74f14el 
c110d224 
f0515be5 
a9136fa9 
Tbc144b8 
fcef1516a 
2de32873 
e8fS5bbf5 
30e202bf 
e897f425 
c898fa72 
73608340 
26092eb4 
5678 12f3 
edd607f4 
5fbedb89 
4634560f 
d09967dd 
c8ad2ffb 


E 


10325476 
98badcfe 
Tbf36ae2 
59d148c0 
ae8d1b7b 
3e6fa2b9 
al387f7d 
c6e0bb6a 
54c7c69d 
e498 14bd 
31c73eab 
cd06ce92 
9e6964c9 
351ff8f1 
c6176d5e 
Ad5a75le 
9ac07210 
d74f14el 
c110d224 
f0515be5 
a9136fa9 
Tbc144b8 
fcf1516a 
2de32873 
e8fS5bbf5 
30e202bf 
e897f425 
c898fa72 
73608340 
26092eb4 
5678 12f3 
edd607f4 
5fbedb89 
4634560f 
d09967dd 
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8fae2fc9 
5337d670 
7044d0fe 
78304e61 
2c5ca6b0 
£304b895 
e89d0d8b 
7930210 
£37223c6 
£53bdd27 
blcf753c 
d9030e9b 
Obf173ff 
bae46f3c 
e8be1481 
4a0bb5b8 
6d99dcd5 
5e0e5623 
422c7e52 
e6ca43ae 
835bd439 
32a7862d 
250ada00 
a46d627b 
0588823a 
2d9bba2e 
8d8fb303 
860d6a4f 
14b64733 
7£486fbe 
7d3d3745 
d17b4506 
2e4967ee 
ccle45de 
b3f80c20 
f124837a 
56ed70b1 
d8b0d990 
1d849b17 
84257988 
9eec3055 
6240e72c 
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B 


a0585c33 
8fae2fc9 
5337d670 
7044d0fe 
78304e61 
2c5ca6bO 
£304b895 
e89d0d8b 
7930210 
£37223c6 
£53bdd27 
blef753c 
d9030e9b 
Obf173ff 
bae46f3c 
e8be1481 
4a0bb5b8 
6d99dcd5 
5e0e5623 
422c7e52 
e6ca43ae 
835bd439 
32a7862d 
250ada00 
a46d627b 
588823a 
2d9bba2e 
8d8fb303 
860d6a4f 
14634733 
7£486fbe 
7d3d3745 
d17b4506 
2e4967ee 
ccle45de 
b3f80c20 
f124837a 
56ed70b1 
d8b0d990 
1d849b17 
84257988 
9eec3055 


Register output 
C 


fff4a467 
e816170c 
63eb8bf2 
14cdf59c 
9c11343f 
5e0c1398 
b1729ac 
Tec12e25 
fa274362 
le7cc084 
bedc88f1 
fd4ef749 
2¢73dd4f 
f640c3a6 
e6fcScff 
2eb9 |bcf 
7a2£8520 
1282ed6e 
5b667735 
d7839588 
908b1f94 
b9b290eb 
60d6f50e 
4ca9e18b 
942b680 
e91b589e 
8162208e 
8b66ee8b 
e363ecc0 
e1835a93 
c52cdlicc 
Ofd2 1 bef 
5f4f4dd1 
b45ed141 
8b9259fb 
b3079177 
2cfe0308 
bc4920de 
55bb5c2c 
362c¢3664 
c76126c5 
21095e62 


D 


6a4e4064 
fff4a467 
e816170c 
63eb8bf2 
14cdf59c 
9c11343f 
5e0c1398 
b1729ac 
Tec12e25 
fa274362 
le7cc084 
bcedc88fl1 
fd4ef749 
2c73dd4f 
f640c3a6 
e6fcScff 
2eb9 | bcf 
7a2f£8520 
1282ed6e 
5b667735 
d7839588 
908b1f94 
b9b290eb 
60d6f50e 
4ca9e18b 
0942b680 
e91b589e 
8162208e 
8b66ee8b 
e363eccO 
e1835a93 
c52cdlicc 
Ofd2 1 bef 
5f4f4dd1 
b45ed141 
8b9259fb 
b3079177 
2cfe0308 
bc4920de 
55bb5c2c 
362c¢3664 
c76126c5 


E 


c8ad2ffb 
6a4e4064 
fff4a467 
e816170c 
63eb8bf2 
14cdf59c 
9c11343f 
5e0c1398 
0b1729ac 
Tec12e25 
fa274362 
le7cc084 
bcedc88fl1 
fd4ef749 
2c73dd4f 
f640c3a6 
e6fcScff 
2eb9 | bcf 
7a2f8520 
1282ed6e 
5b667735 
d7839588 
908b1£94 
b9b290eb 
60d6f50e 
4ca9e18b 
0942b680 
e91b589e 
8162208e 
8b66ee8b 
e363ecc0 
e1835a93 
c52cdlcc 
Ofd2 1 bef 
5f4f4dd1 
b45ed141 
8b9259fb 
b3079177 
2cfe0308 
bc4920de 
55bb5c2c 
362c¢3664 
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Register output 
t A B C D E 


77 8243ecda 6240e72c 67bb0c 15 21095e62 c76126c5 
78 a8342af0 8243ecda 189039cb 67bb0c 15 21095e62 
79 e1426096 a8342af0 a090fb36 189039cb 67bb0c 15 


After all 512-bit blocks have been processed, the output represented by the five words, 
Ho, H,, Hy, Hz and Hy, is the 160-bit message digest as shown below: 


Ho: 48878397 
H,: 9801d679 
HA: 394bd834 
F3: 28c28e41 
Hy: 2b8dee05 


The 160-bit message digest is then the data concatenation of {Hj}: 
A|| Ai || H2|| 43 || Ha = 488783979801d679394bd83428c28e4 1 2b8dee05 


As discussed previously, the digitised document or message of any length can create a 
160-bit message digest which is produced using the SHA-1 algorithm. 

Any change to a digitised message in transit results in a different message digest. In 
fact, changing a single bit of the data modifies at least half of the resulting digest bits. 
Furthermore, it is computationally impossible to find two meaningful messages that have 
the same 160-bit digest. On the other hand, given a 160-bit message digest, it is also 
impossible to find a meaningful message with that digest. 


4.5 Hashed Message Authentication Codes (HMAC) 


The keyed-hashing Message Authentication Code (HMAC) is a key-dependent one-way 
hash function which provides both data integrity and data origin authentication for files 
sent between two users. HMACs have the same properties as the one-way hash functions 
discussed earlier in this chapter, but they also include a secret key. HMACs can be 
used to authenticate data or files between two users (data authentication). They can also 
be used by a single user to determine whether or not his files have been altered (data 
integrity). 

To evaluate HMAC over the message or file, the following expression is required 
to compute: 


HMAC = H[(K © opad)|| H[(K @ ipad)||M]] 


where ipad = inner padding 
= 0 x 36 (repeated b times) 
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= 00110110 (0 x 36) repeated 64 times (512 bits) 
opad = outer padding 

= 0 x Sc (repeated b times) 

= 01011100 (0 x 5c) repeated 64 times (512 bits) 


b: Block length of 64 bytes = 512 bits 
h: Length of hash values, i.e. h = 16bytes = 128 bits for MD5 
and h = 20bytes = 160 bits for SHA-1. 
K: Secret key of any length up to b = 512 bits. 
H: Hash function where message is hashed by iterating a basic key K. 


The HMAC equation is explained as follows: 


1. Append zeros to the end of K to create a b-byte string (i.e. if K = 160 bits in length 
and b = 512 bits, then K should be appended with 352 zero bits or 44 zero bytes 
0x00, resulting in K’ = (K||0x00) 

2. XOR (bitwise exclusive-OR) K’ with ipad to produce the b-bit block computed in 
step 1. 

3. Append M to the b-byte string resulting from step 2. 

4. Apply H to the stream generated in step 3. 


5. XOR (bitwise exclusive-OR) K’ with opad to produce the b-byte string computed in 
step 1. 

6. Append the hash result H from step 4 to the b-byte string resulting from step 5. 

7. Apply H to the stream generated in step 6 and output the result. 


Figure 4.14 illustrates the overall operation of HMAC, explaining the steps, listed above. 


Example 4.8 Consider HMAC computation by using a hash function SHA-1. Assume 
that the message (M), the key (K) and the initialisation vector (IV) are given as fol- 
lows: 
M: Ox1a7fd53b4c 
K: 0x31fa7062c45113e32679fd1353b71264 
IV: A = 0x67452301, B = Oxefcdab89, C = 0x98badcfe, 

D = 0x10325476, E = 0xc3d2e1f0 


Referring to Figure 4.14, the HMAC-—SHA-1 calculation proceeds with the steps shown 
below: 


K' = K||(0x00.. .00)(512 bits) 


= 31fa7062 c45113e3 2679fd13. 53b71264 
00000000 00000000 00000000 00000000 
00000000 00000000 00000000 00000000 
00000000 00000000 00000000 00000000 
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Figure 4.14 Overall operation of HMAC computation using either MD5 or SHA-1 (message 
length computation is based on Q2;||M). 


Q; = K' @ ipad = K' @ (0x3636.. . 36) 


= 07cc4654 £26725d5 104fcb25 65812452 
36363636 36363636 36363636 36363636 
36363636 36363636 36363636 36363636 
36363636 36363636 36363636 36363636 


M’ = 1a7fd53b 4c800000 00000000 00000000 


00000000 00000000 00000000 00000000 
00000000 00000000 00000000 00000000 
00000000 00000000 00000000 00000228 


Q;\|M’ : 


O7cc4654 = £26725d5 104fcb25 65812452 
36363636 36363636 36363636 36363636 
36363636 36363636 36363636 36363636 
36363636 36363636 36363636 36363636 
la7fd53b 4c800000 00000000 00000000 
00000000 00000000 00000000 00000000 
00000000 00000000 00000000 00000000 
00000000 00000000 00000000 00000228 
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h = H(M',IV;) = Inner SHA-1 
= 9691leb0c d263al2f ab7e0e2f e60ced5f 546c857a 


Q. = K' ® opad = K' @ (Ox5c5c... 5c) 


= 6da62c3e 980d4fbf 7a25al4f Ofeb4e38 
SeS5c5c5ce 5c5c5c5ce S5ceS5c5c5e S5cS5c5c5c 
SeS5cS5e5ce 5c5c5c5ce S5ceS5c5c5ce S5cS5c5c5c 
SeS5cS5ce5ce 5c5c5c5c S5ceS5c5c5e S5cS5c5c5c 


h'=969leb0c d263al2f ab7eO0e2f e60ced5f 
546c857a 80000000 00000000 00000000 
00000000 00000000 00000000 00000000 
00000000 00000000 00000000 000002a0 


Qol|h’ : 
6da62c3e 980d4fbf 7a25al4f Ofeb4e38 
SeS5cS5e5e SeS5c5c5ce S5ce5c5c5c =5c5c5c5c 
SeS5cS5e5e SeS5c5c5ce S5c5c5c5ce =5c5c5c5c 
SeS5ceS5e5e SeS5c5c5ce S5ce5c5c5c = 5c5c5c5c 
969leb0c d263al2f ab7eO0e2f e60ced5f 
546c857a 80000000 00000000 00000000 
00000000 00000000 00000000 00000000 
00000000 00000000 00000000 000002a0 


HMAC{[Q,||h’] = Outer SHA-1 
= 19e1236 ae346195 16594259 4c5202b3 4a85cSe 


The alternative operation for computation of either HMAC-MD5 or HMAC-SHA-1 is 
based on the following expression: 


HMAC = H[H[M, (1V);], (V)o] 
(IV); = f[(K’ © ipad), IV] 
(IV), = f[(K’ ® opad), IV] 
K' = K|\(0x00...0) (512bits) 


The procedure can be explained in words as follows: 


1. Append zeros to K to create a b-bit string K’, where b = 512 bits. 
. XOR K’ (padding with zero) with ipad to produce the b-bit block. 
3. Apply the compression function f(K’® ipad, IV) to produce (IV); = 160 bits for 
SHA-1. 
4. Compute the hash code A with (IV); and M;. 
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di 


Raise the hash value computed from step 4 to a b-bit string. 

XOR K’' (padded with zeros) with opad to produce the b-bit block. 

7. Apply the compression function f(K’@ opad, IV) to produce (IV), = 160 bits for 
SHA-1. 

8. Compute the HMAC with (IV), and the raised hash value resulted from step 5. 


a 


Figure 4.15 shows the alternative scheme based on the above steps. 


Example 4.9 Consider the HMAC computation by the alternative method. Assume that 
the message (M), the key (K) and the initialisation vector (IV) are given as follows: 


M : Ox 1a7fd53b4c 

K : Ox 31fa7062c45113e32679fd1353b71264 

IV: A = 0x67452301, B = Oxefcdab89, C = Ox98badcfe, 
D = 0x10325476, E = Oxc3d2e1f0. 
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Figure 4.15 Alternative operation of HMAC computation using MD5 or SHA-1 (message length 
computation is based on M only). 


160 INTERNET SECURITY 


Referring to Figure 4.15, the HMAC-SHA-1 calculation proceeds in the steps shown 
below: 


K' = K||(0x00.. .00)(512bits) 


= 31fa7062 c45113e3 2679fd13 53b71264 
00000000 00000000 00000000 00000000 
00000000 00000000 00000000 00000000 
00000000 00000000 00000000 00000000 


Q; = K' @ ipad = K' @ (0x3636.. . 36) 


= 07cc4654 £26725d5 104fcb25 65812452 
36363636 36363636 36363636 36363636 
36363636 36363636 36363636 36363636 
36363636 36363636 36363636 36363636 


(IV); = f(Q:, IV) 
= c6edf676 ef938cee 84dd1b00 5b3b8996 cb172ad4 


M' = la7fd53b —4c800000 00000000 00000000 
00000000 00000000 00000000 00000000 
00000000 00000000 00000000 00000000 
00000000 00000000 00000000 00000028 


h = H(M',IV;) = Inner SHA-1 
= 613f6cbd b336740e 8af4b185 367b1773 d260afce 


Q, = K’ ® opad = K' @ (Ox5c5c... 5c) 


= 6da62c3e 980d4fbf 7a25al4f Ofeb4e38 
SceS5c5c5e S5cS5c5c5ce S5c5c5c5e S5c5c5c5c 
SeSe5c5e S5c5c5c5c S5c5c5c5e = 5c5c5c5c 
SeSe5ce5e S5c5c5c5c S5c5c5c5e =5c5c5c5c 


(IV)o = f(Qbo, IV) 
= A46e7eba 64c80ca4 c42317b3 dd2b4fle 81c21ab0 
Outer SHA-1 = H(h’, (IV),) 
= af625840 ed120ccd ba408de3 b259a95b d4d98eda 
The HMAC is a cryptographic checksum with the highest degree of security against 
attacks. HMACs are used to exchange information between two parties, where both have 


knowledge of the secret key. A digital signature does not require any secret key to 
be verified. 


5 


Asymmetric Public-key Cryptosystems 


Public-key cryptography became public soon after Whitefield Diffie and Martin Hellman 
(1976) proposed the innovative concept of an exponential key exchange scheme. Since 
1976, numerous public-key algorithms have been proposed, but many of them have since 
been broken. Of the many algorithms that are still considered to be secure, most are 
impractical. 

Only a few public-key algorithms are both secure and practical. Of these, only some 
are suitable for encryption. Others are only suitable for digital signatures. Among these 
numerous public-key cryptography algorithms, only four algorithms, RSA (1978) and 
ElGamal (1985), Schnorr (1990) and ECC (1985) are considered to be suitable for both 
encryption and digital signatures. Another public-key algorithm that is designed to only 
be suitable for secure digital signatures is DSA (1991). The designer should bear in mind 
that the security of any encryption scheme depends on the length of the key and the 
computational work involved in breaking a cipher. 


5.1 Diffie-Hellman Exponential Key Exchange 


In 1976, Diffie and Hellman proposed a scheme using the exponentiation modulo g (a 
prime) as a public key exchange algorithm. Exponential key exchange takes advantage of 
easy computation of exponentials in a finite field GF(qg) with a prime g compared with 
the difficulty of computing logarithms over GF(q) with g elements {1,2,..., gq — 1}. Let 
q be a prime number and a a primitive element of the prime number g. Then the powers 
of a generate all the distinct integers from | to g — 1 in some order. For any integer Y 
and a primitive element a of prime number gq, a unique exponent X is found such that 


Y =aX* (mod q),1<X<q-1 
Then X is referred to as the discrete logarithm of Y to the base a over GF(q): 


X = log a’ over GF(q), 1< Y <q -1 
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Calculation of Y from X is comparatively easy, using repeated squaring, but computation 
of X from Y is typically far more difficult. 

Suppose the user i chooses a random integer X; and the user j a random integer X;. 
Then the user i picks a random number X; from the integer set {1,2,...,gq@ — 1}. The 
user i keeps X; secret, but sends 


Y; =a (mod q) 
to the user j. Similarly, the user 7 chooses a random integer Xj; and sends 
Y,;= a* (mod q) 
to the user i. 
Both users i and j can now compute: 
Kj = a*'Xi (mod q) 


and use K,; as their common key. 
The user i computes Ky by raising Y; to the power X;: 


Ki = Y;" (mod q) 

= (a/)™ (mod q) 

= a"! = gX% (mod g) 
and the user j computes Kj in a similar fashion: 
Kj = ye (mod q) 

= (a) = a*) (mod q) 


Thus, both users i and j have exchanged a secret key. Since X; and Xj are private, the 
only available factors are the public values g, a, Y; and Y;. Therefore the opponent is 
forced to compute a discrete logarithm which is considered to be unrealistic, particularly 
for large primes. Figure 5.1 illustrates the Diffie-Hellman key exchange scheme. 

When utilising finite field GF(q), where g is either a prime or g = 2", it is necessary to 
ensure the gq — | factor has a large prime, otherwise it is easy to find discrete logarithms 
in GF(q). 


Example 5.1 Consider a prime field Z, where g is a prime modulus. If @ is a primitive 
root of the modulus qg, then a generates the set of nonzero integer modulo g such that 
a, a7,...,@7—!, These powers of o are all distinct and are all relatively prime to g. Given 
a,l1<a<q-1, and gq = 11, all the primitive elements of g are computed as shown in 
Table 5.1. 

For the modulus g = 11, the primitive elements are a = 2, 6,7 and 8 whose order is 10, 


respectively. 


Example 5.2 Consider a finite field GF(q) of a prime g. Choose a primitive element 
a = 2 of the modulus g = 11. 
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User A User B 
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random integer random integer 
x y 
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{|—— 


Compute a* (mod p) Compute a” (mod p) 
and place it in and place it in 
a public file a public file 
































Compute key Compute key 
(@)' (mod p) (a*Y (mod p) 

















Common secret key 
a*’ (mod p) 














a: A primitive element of 
the finite GF (p) (1 <a<p) 








Figure 5.1 The Diffie-Hellman exponential key exchange scheme. 


Table 5.1 Powers of primitive element a (over Z;;) 


é 2 Pe at Pe 9 ait a @? 0 
1 1 1 1 1 1 1 1 1 1 
2 4 8 5 10 9 7 3 6 1 
3 9 5 4 1 3 9 5 4 1 
4 5 9 3 1 4 5 9 3 1 
5 3 4 9 1 5 3 4 9 1 
6 3 7 9 10 5 8 4 2 1 
7 5 2 3 10 4 6 9 8 1 
8 9 6 4 10 3 2 5 7 1 
9 4 3 5 1 9 4 3 5 1 

10 1 10 1 10 1 10 1 10 1 
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Compute: 


2 (1 <aA<10): 2! 22 23 24 25 26 97 28 29 210 
2 (mod 11) : 2 4 8 5 109 7 3 61 


To initiate communication, the user i chooses X; =5 randomly from the integer set 
2* (mod 11) = {1, 2,..., 10} and keep it secret. The user i sends 


Y; = a“' (mod q) 

= 2° (mod 11) = 10 
to the user j. Similarly, the user j chooses a random number Xj; = 7 and sends 
Y,;= a* (mod q) 

= 2’ (mod 11) =7 


to the user i. 
Finally, compute their common key Kj as follows: 


Ki = Yi" (mod q) 
= 7 (mod 11) = 10 
and 
— yx 
Kj = Y;" (mod q) 
= 10’ (mod 11) = 10 


Thus, each user computes the common key. 


Example 5.3 Consider the key exchange problem in the finite field GF(2”) for m = 3. 
The primitive polynonial p(x) of degree m = 3 over GF(2) is p(x) =1+x+.x?. If a 
is a root of p(x) over GF(2), then the field elements of GF(2*) generated by p(a) = 
1+a@-+a? =0 are shown in Table 5.2. 


Table 5.2. Field elements of GF(2*) 


forg =7 
Power Polynonial Vector 
1 1 100 
a a 010 
a? a? 001 
a? l+a 110 
at ata? 011 
a l+a+a’ 111 
a 1 +a? 101 
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Suppose users i and j select X; = 2 and X; =5, respectively. Both X; and X; are 
kept secret, but 


Y; =a“ (mod qg) = a” (mod 7) = 001 
and Y; = a! (mod QgQ= a> (mod 7) = 111 


are placed in the public file. User i can communicate with user j by taking Y; = 111 
from the public file and computing their common key Kj as follows: 


Ky = (Y;)™" (mod q) 
= (a>)? (mod 7) = a!” (mod 7) = a? = 110 


User j computes Kj in a similer fashion: 
Ky = (%)* (mod q) = (a)? (mod 7) = a'® (mod 7) = a? = 110 


Thus two users i and j arrive at a key Ky in common. These examples are extremely 
small in size and are intended only to illustrate the technique. So far, we have shown 
how to calculate the Diffie-Hellman key exchange, the security of which lies in the fact 
that it is very difficult to compute discrete logarithms for large primes. 

This pioneering work relating to the key-exchange algorithm introduced a new approach 
to cryptography that met the requirements for public-key systems. The first response to the 
challenge was the development of the RSA scheme which was the only widely accepted 
approach to the public key encryption. The RSA cryptosystem will be examined in the 
next section. 


5.2 RSA Public-key Cryptosystem 


In 1976, Diffie and Hellman introduced the idea of the exponential key exchange. In 1977 
Rivest, Schamir and Adleman invented the RSA algorithm for encryption and digital sig- 
natures which was the first public-key cryptosystem. Soon after the publication of the RSA 
algorithm, Merkle and Hellman devised a public-key cryptosystem for encryption based 
on the knapsack algorithm. The RSA cryptosystem resembles the D-H key exchange 
system in using exponentiation in modula arithmetic for its encryption and decryption, 
except that RSA operates its arithmetic over the composite numbers. Even though the 
cryptanalysis was researched for many years for RSA’s security, it is still popular and 
reliable. The security of RSA depends on the problem of factoring large numbers. It is 
proved that 110-digit numbers are being factored with the power of current factoring 
technology. To keep RSA’s level of security, more than 150-digit values for n will be 
required. The speed of RSA does not beats DES, because DES is about 100 times faster 
than RSA in software. 


5.2.1 RSA Encryption Algorithm 


Given the public key e and the modulus n, the private key d for decryption has to be found 
by factoring n. Choose two large prime numbers, p and g, and compute the modulus n 
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which is the product of two primes: 


n= pq 


Choose the encryption key e such that e and ¢(n) are coprime, i.e. ged (e, d(m)) = 1, in 
which ¢(n) = (p — 1)(q — 1) is called Euler’s totient function. 

Using euclidean algorithm, the private key d for decryption can be computed by taking 
the multiplicative inverse of e such that 


d =e! (mod g(n)) 
or ed = | (mod ¢(n)) 


The decryption key d and the modulus n are also relatively prime. The numbers e and n 
are called the public keys, while the number d is called the private key. 

To encrypt a message m, the ciphertext c corresponding to the message block can be 
found using the following encryption formula: 


c=m* (mod n) 


To decrypt the ciphertext c, c is raised to the power d in order to recover the message m 
as follows: 


m = c¢ (mod n) 


It is proved that 








ct =(m°)? = m@ =m (mod n) 


due to the fact that ed = 1 (mod ¢(n)). 

Because Euler’s formula is m?) = 1 (mod n), the message m is relatively prime to n 
such that gcd (m,n) = 1. Since m*®™ = 1 (mod n) for some integer A, it can be written 
m*?O+! = m (mod n), because m*?™*! = mm*?™ = m (mod n). Thus, the message m 
can be restored. 

Figure 5.2 and Table 5.3 illustrate the RSA algorithm for encryption and decryption. 

Using Table 5.3, the following examples are demonstrated. 


Example 5.4 If p = 17 and q = 31 are chosen, then 
n= pq =17x 31 =527 
o(n) = (:p — D(q — 1) = 16 x 30 = 480 
If e = 7 is chosen, then compute: 
d =e! (mod ¢(n)) = 7"! (mod 480) = 343 
This decryption key d is calculated using the extended euclidean algorithm. 


ed = 7 x 343 (mod 480) = 2401 (mod 480) = 1 
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Figure 5.2. RSA public-key cryptosystem for encryption/decryption. 


Table 5.3. RSA encryption algorithm 
Public key e: 


n (product of two primes p and q (secret integers)) 
e (encryption key, relatively prime to ¢(n) = (p — 1) (¢ — 1)) 


Private key d: 


d (decryption key, d = e~! (mod ¢(n)) 
ed = 1 (mod ¢(n)) 


Encryption: 
c =m¢* (mod n), where m is a plaintext. 
Decryption: 


m = c4 (mod n), where c is a ciphertext. 


The public key (e, m) is required for encryption of m. If m = 2, then the message m is 
encrypted as: 


c =m* (mod n) 


= 2’ (mod 527) = 128 
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To decipher, the private key d is needed to compute the message as follows: 
m = c¢ (mod n) 


= 128°" (mod 527) =2 


Example 5.5 If p = 47 and q = 71, then compute 
n= pq =47 x 71 = 3337 
o(n) = (p— 1)(q — 1) = 46 x 70 = 3220 


Choose the encryption key e = 79 randomly such that gcd (e, @(n)) = ged (79, 3220) = 1, 
ie. e and ¢(n) are relatively prime. Using the extended euclidean algorithm (i.e. gcd 
(e, d(n)) = 1 = ed + d(n)s), compute the decryption key d such that: 


ed = 1 (mod ¢(n)) 
79d = 1 (mod 3220) 
3220 = 79 x 40 + 60 
79 = 60+ 19 
60 = 19x 343 
19=3 x 6+1— gcd(79, 3220) = 1 (coprime) 
1=19-3x6=19- (60-19 x 3) x 6 
= 19x 19-606 
1 = (79 — 60) x 19- 60 x 6 
= 79 x 19 — 60 x 25 
1 = 79 x 19 — (3220 — 79 x 40) x 25 
= 79 x 1019 — 3220 x 25 
(79)(1019) = 1 (mod 3220) 
d = 1019 (privatekey) 
To encrypt a message m = 688 with e = 79, compute: 
c =m° (mod n) = 688” (mod 3337) 
6887 (mod 3337) = 2827, 688* (mod 3337) = 3151 
688° (mod 3337) = 1226, 688'° (mod 3337) = 1426 
688°" (mod 3337) = 1243, 688™ (mod 3337) = 18 
c = 688” (mod 3337) = 688% t8+4+2+1 
= 18 x 1426 x 3151 x 2827 x 688 (mod 3337) 
= 1570 (mod 3337) 
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To decrypt a message, perform the same exponentiation process using the decryption key 
d = 1019 such that: 


m = c4 (mod n) = 1570!°'? (mod 3337) 
m = (1570)?!? x (1570)?°° x (1570)!?8 x (1570) x (1570)*? 
x (1570)!° x (1570)® x (1570)? x (1570) 
= 3925000 (mod 3337) = 688 


Thus, the message is recovered. 

To encrypt the message m, break it into a series of m;-digit blocks, | <<i<n-1. 
Suppose each character in the message is represented by a two-digit number as shown in 
Table 5.4. 


Example 5.6 Encode the message ‘INFORMATION SECURITY’ using Table 5.4. 
m = (0914061518130120091514001905032118092025) 
Choose p = 47 and g = 71. Then 
n = pq = 47 x 71 = 3337 
o(n) = (p— Dig - 1) = 46 x 70 = 3220 
Break the message m into blocks of four digits each: 


0914 0615 1813 0120 0915 
1400 1905 0321 1809 2025 


Choose the encryption key e = 79. Then the decryption key d becomes: 
d =e! (mod ¢(n)) = 797! (mod 3220) = 1019 


The first block, m; = 914, is encrypted by raising it to the power e = 79 and dividing by 
n = 3337 and taking the remainder c; = 3223 as the first block of ciphertext: 


c, =m‘ (mod n) 
= 914” (mod 3337) 
= 3223 


Table 5.4 Two-digit number representing each character 


Blank 00 E 05 J 10 O 15 T 20 Y 25 
A 01 F 06 K 11 P 16 U 21 Z 26 
B 02 G 07 L 12 Q 17 Vv 22 
Cc 03 H 08 M 13 R 18 W 23 
D 04 I 09 N 14 S 19 x 24 
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Thus, the whole ciphertext blocks c;, 1 < i < 10, are computed as: 


3223 3155 1012 1712 1595 
2653 0802 2360 0832 1369 


To decrypt the first ciphertext c; = 3223, use the decryption key, d = 1019, and compute: 
m= ef (mod n) 

= 3223!°!9 (mod 3337) = 914 
m= c (mod n) 


= 3155!°9 (mod 3337) = 615 


The recreated message of this example is computed as: 


0914 0615 1813 0120 0915 
1400 1905 0321 1809 2025 


5.2.2 RSA Signature Scheme 


The RSA public-key cryptosystem can be used for both encryption and signatures. Each 
user has three integers e, d and n,n = pq with p and gq large primes. For the key pair 
(e,d), ed = 1 (mod ¢(n)) must be satisfied. If sender A wants to send signed message c 
corresponding to message m to receiver B, A signs it using A’s private key, computing 
c =m“ (mod na). First A computes 


g(na) = Iem (pa — 1, Ga — 1) 


where Icm stands for the least common multiple. The sender A selects his own key pair 
(e4, d4) such that 


eard, = | (mod g(nq)) 
The modulus n, and the public key e, are published., Figure 5.3 illustrates the RSA 
signature scheme. 
Example 5.7 Choose p = 11 and q = 17. Then n = pg = 187. 
Compute g(n) = 1 cm (p—1,q —- 1) 
= 1 cm (10, 16) = 80 
Select e4 = 27. Then e,d, = 1 (mod g(na)) 
27d, = 1 (mod 80) 
dy =3 
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Figure 5.3 The RSA signature scheme. 


Suppose m = 55. Then the signed message is 


c =m (mod 187) 


= 55° (mod 187) = 132 
The message will be recreated as: 


m =c“ (mod n) 


= 1327’ (mod 187) = 55 


Thus, the message m is accepted as authentic. 


Next, consider a case where the message is much longer. The larger m requires more com- 
putation in signing and verification steps. Therefore, it is better to compute the message 
digest using a appropriate hash function, for example, the SHA-1! algorithm. Signing 
the message digest rather than the message often improves the efficiency of the process 
because the message digest is usually much smaller than the message. 

When the message is assumed to be m = 75 139, the message digest h of m is computed 
using the SHA-1 algorithm as follows: 


h = H(m) (mod n) 
= H(75 139) (mod 187) 
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= 86a0aab563 1e729b0730757b0770947307d9f597 
= 768587753333627872847426508024461003561962698135 
(mod 187) (decimal) 


The message digest h is then computed as: 
h = H(75 139) (mod 187) = 11 
Signing h with A’s private key d4 produces: 
c =h” (mod n) 
= 11° (mod 187) = 22 
Thus, the signature verification proceeds as follows: 
h=c% (mod n) 


= 22’ (mod 187) = 11 


which shows that verification is accomplished. 

In hardware, RSA is about 1000 times slower than DES. RSA is also implemented 
in smartcards, but these implementations are slower. DES is about 100 times faster than 
RSA. However, RSA will never reach the speed of symmetric cipher algorithms. 

It is known that the security of RSA depends on the problem of factoring large numbers. 
To find the private key from the public key e and the modulus n, one has to factor n. 
Currently, n must be larger than a 129 decimal digit modulus. Easy methods to break 
RSA have not yet been found. A brute-force attack is even less efficient than trying to 
factor n. RSA encryption and signature verification are faster if you use a low value for 
e, but can be insecure. 


5.3 ElGamal’s Public-key Cryptosystem 


ElGamal proposed a public-key cryptosystem in 1985. The ElGamal algorithm can be 
used for both encryption and digital signatures. The security of the ElGamal scheme 
relies on the difficulty of computing discrete logarithms over GF(p) where p is a large 
prime. Prime factorisation and discrete logarithms are required to implement the RSA and 
ElGamal cryptosystems. 

In the RSA cryptosystems, each user has three integers e, d and n, where n = pq with 
two large primes p and q, and ed = 1(mod ¢(n)), ¢ being Euler’s totient function. User 
A has a public key consisting of the pair (e4, n4) and a private key d,; similarly, user B 
has (eg, ng) and dg. To encrypt the message m to B, A uses B’s public key for computing 
the encrypted message (or ciphertext) such that c = m** (mod ng). If A wants to send 
the signed message to B, A signs the message m using his own private key da such that 
c =m (mod na). 

To describe the ElGamal system, choose a prime number p and two random numbers, 
g and x, such that both g < p and x < p, where x is a private key. The random number g 
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is a primitive root modulo p. The public key is defined by y, g and p. Then we compute 
y = g* (mod p). To encrypt the message m, 0 < m < p —1, first pick a random number 
k such that ged (k, p — 1) = 1. The encrypted message (or ciphertext) can be expressed 
by the pair (7, s) as follows: 


r= gk (mod p) 
s = (y‘m (mod p)) (m (mod p — 1)) 


To decrypt m, divide s by r* such that s/r* = m (mod p — 1). To sign a given message 
m, first choose a random number & such that gcd (k, p — 1) = 1, and compute m = xr + 
ks (mod p — 1) using the extended euclidean algorithm to solve s. The basic technique 
for encryption and signature using the ElGamal algorithm as a two-key cryptosystem is 
described in the following section. 


5.3.1  ElGamal Encryption 


To generate a key pair, first choose a prime p and two random numbers g and x such 
that g < p and x < p. Then compute 


y = g" (mod p) 


The public key is (y, g, p) and the private key is x < p. 
To encrypt the message m,0 <m < p —1, first choose a random number k such that 
gcd (k, p — 1) = 1. The encrypted message (or ciphertext) is then the following pair (, s): 


r = g* (mod p) 
s = (y* (mod p)) (m(mod p — 1)) 


Note that the size of the ciphertext is double the size of the message. To decrypt the 
message, divide s by r*, as shown below: 


r* = (g*)* (mod p) 
s/r* = ykm/(g*)* = (g*)km/(g*)* = m (mod p — 1) 


The ElGamal encryption scheme is plotted in Figure 5.4 and Table 5.5. 


Example 5.8 Choose: 
p = 11 (a prime) 
g =4 (a random number such thatg < p) 


x = 8 (a private key such thatx < p) 
Then compute: 


y = g* (mod p) = 4° (mod 11) =9 
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Figure 5.4 The ElGamal encryption scheme. 


Table 5.5 ElGamal encryption algorithm 
Public key: 


p (a prime number) 

g,x < p (two random numbers) 
y = g* (mod p) 

y, g and p: public key 


Private key: 
x<p 
Enciphering: 


k: a random number such that gcd (k, p— 1) = 1 
r = g* (mod p) 
s = (y* (mod p)) (m(mod p — 1)) 


Deciphering: 


m=s/r* (mod p),0O<m< p-1 


The public key is y= 9, g = 4 and p = 11. The private key x = 8 is given above. To 
encrypt the message m = 5, first choose a random number k = 7 such that gcd (k, p — 
1) = gcd (7, 10) = 1 and compute: 
r = g* (mod p) =4’ (mod 11) =5 
s = (y* (mod p)) (m (mod p — 1)) 

= (9’ (mod 11)) (5 (mod 10) = 4 x 5 = 20 
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To decipher the message m, first compute: 
r* (mod p) = 5° (mod 11) =4 
and take the ratio: 


m=s/r* (mod p) = 20/4=5 


It thus proves that the message m is completely restored using the ElGamal encryption 
algorithm (see Table 5.5) 


5.3.2 ElGamal Signatures 


To sign a message m, first choose a random number &k such that gcd (k, p—1) =1 
(relatively prime). The public key is described by 


y =g" (mod p) 


where the private key is x < p. Let m be a message to be signed, 0 < m < p — 1. Choose 
first a random number k such that gcd (k, p — 1) = 1 (relatively prime). Then compute 


r= gk (mod p) 


The signature for m is the pair (7,s),O<r,s <p-—l. 


m 


g” = y'r* (mod p) 
(g*)" (g*)* (mod p) 
= gah (mod p) 


from which 
m =xr+ks (mod p — 1) 


Use the extended euclidean algorithm to solve s. The signature for m is the pair (7, s). 
The random number s should be kept secret. To verify a signature, confirm that: 


y’r® (mod p) = g” (mod p) 
Figure 5.5 illustrates the ElGamal signature scheme based on Table 5.6. 
Example 5.9 To sign a message m, first choose a prime p = 11 and two random num- 


bers g = 7 and x = 3, where x < p is a private key. 
Compute: 


y = g* (mod p) = 7 (mod 11) =2 


The public key is y= 2, g =7 and p= 11. 
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Figure 5.5 The ElGamal signature scheme. 


Table 5.6 ElGamal signature algorithm 


Public key: 


p (a prime number) 


g < p (a random number) 


y = g* (mod p) where x < p 


Private key: 


k: a random number 
r= gk (mod p) 


s: compute from m = xr + ks (mod p — 1) 


Verifying: 


Accept as valid if 
y’r® (mod p) = g” (mod p) 
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To authenticate m= 6, choose a random number k =7 such that gcd (k, p— 1) 
= gcd (7, 10) = 1. Compute: 
r = g* (mod p) =7’ (mod 11) =6 
m = xr +ks (mod p — 1) (euclidean algorithm to solve for s) 
6=3x6+7s (mod 10) 
7s = —2 (mod 10) = 28 (mod 10) 
s = 4 (mod 10) 


The signature is the pair of r = 6 and s = 4. 
To verify a signature, it must be confirmed that 


y'r* (mod p) = g” (mod p) 

(2°) (6*) (mod 11) = 7° (mod 11) 
81 (mod 11) = 15 (mod 11) 

4 (mod 11) = 4 (mod 11) 


5.3.3 ElGamal Authentication Scheme 


The ElGamal signature or authentication scheme looking at another angle is to describe 
in the following. 

The sender chooses a finite field GF(p) where p is a prime. Let g be a primitive 
element of GF(:p). First choose two random integers g and x such that g < p and x < p. 
A key x is kept secret by both the sender and the receiver. Let m denote a message which 
is relatively prime to p. Then compute: 


u = g” (mod p) 


Let c denote a ciphertext such that gcd (c, p) = 1. 
Using the extended euclidean algorithm, the following congruence is to solve for v: 


c =xu+mv (mod p-— 1) 
or v =m! (c — xu) (mod p—1) 


To authenticate the ciphertext c, the signed cryptogram (c,u,v) is transmitted to the 
receiver. Upon receipt of (c, u, v), the receiver computes 
A = (g*)“u" (mod p) 

=" (g")” (mod p) 
= g° (mod p) 


Thus, the ciphertext c is accepted as authentic if A = g° (mod p). Once this ciphertext 
has been accepted, the message m is recovered by: 


m=v_! (c — xu) (mod p— 1) 


178 INTERNET SECURITY 


The ElGamal authentication scheme is shown in Figure 5.6. The ElGamal authentication 
algorithm given in Table 5.7 is illustrated by the following example. 


Example 5.10 Take the finite field GF(11). Then the set of primitive elements of GF(11) 
is {2,6, 7,8}. Choose a primitive element g = 7 from the set. Define the public key 
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Figure 5.6 The ElGamal authentication scheme. 


Table 5.7 ElGamal authentication algorithm 
Sender 


p (a prime integer) 

& < p (a primitive element of GF(p)) 

u = g™ (mod p) where m < p is a message. 

x < p (a private key) 

c (ciphertext) 

c =xu + mv: solve for v 

(c,u, v): (the signed cryptogram to be transmitted) 


Receiver 
A = (g*)"u" (mod p) 
Verifying: 


Accept as valid if and only if A = g° (mod p) 
Decryption: 
m=v—'(c — xu) (mod p — 1) 
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as (g, p) = (7,11) and x =5 as the chosen private key which is shared by both the 
sender and the receiver. If the sender now wants to transmit a message m = 3 such that 
gcd(m, p) = gcd(3, 11) = 1, then compute first: 


u = g” (mod p) =7* (mod 11) =2 

Next, compute v by solving the following congruence: 
c =xu+mv (mod p-— 1) 
7=5x2-+3v (mod 10) 

3v =7 (mod 10) 
v = 9 (mod 10) 


where c = 7 is assumed. 
Send the signed cryptogram (c, u, v) = (7, 2,9) to the receiver. At the receiving end, 
compute: 


A = (g*)“u" (mod p) 
= (7°)*2°(mod 11) 
= (10°)(2’) (mod 11) = 6 
and A=g‘° (mod p) =7’ (mod 11) =6 


Thus, the cryptogram (7, 2, 9) is accepted, and c = 7 is authentic. Finally, the message 
is restored in the following manner: 


m 


v! (ce — xu) (mod p — 1) 
9-'(7 —5 x 2)(mod 10) 
= (9"') (7) (mod 10) = 3 


The message m = 3 has been completely recovered. 


5.4 Schnorr’s Public-key Cryptosystem 


In 1990, Schnorr introduced his authentication and signature schemes based on dis- 
crete logarithms. 


5.4.1. Schnorr’s Authentication Algorithm 


First choose two primes, p and q, such that gq (1 <q < p-—1) is a prime factor of 
p —1. To generate a public key, choose a 4 1 such that a = h’~/4 (mod p), that is, 
a’ =h?—' (mod p). If h is relatively prime to p, by Fermat’s theorem it can then be 
written as h?-' = 1 (mod p). As a result, we have a? = 1 (mod p), 1 <a < p—1. All 
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these numbers, p, g and a, can be freely published and shared with a group of users. To 
generate a key pair, choose a random number s < g which is used as the private key. 
Next, compute 4 = a~* (mod p) which is the public key. 

Now, user A picks a random number r < g and computes x =a" (mod p). User B 
picks a random number ¢ and sends it to the user A, where ¢ € (0,1, 2,..., 2” — 1) indi- 
cates the security level. Schnorr recommends the value of v = 72 for sufficient security. 
User A computes y = r + st (mod q) and sends it to user B. Thus, user B tests verification 
of authenticity such that x = a’A' (mod p). Figure 5.7 illustrates Schnorr’s authentication 
scheme, and Table 5.8 shows the related algorithm. 


Example 5.11 Choose two primes p = 23 and q = 11 such that g = 11 is a prime factor 
of p — 1 = 22. Choose a = 3 satisfying a1 = 1 (mod p), i.e. 3'! = 1 (mod 23). Choose 
s = 8 <q as the private key and compute the public key such that 1 = a~* (mod p) 
3-8 (mod 23). Compute the multiplicative inverse of a = 3: aa~! = 1 (mod p), 3a7! 
1 (mod 23) from which a~! = 8. Thus, 4 = 8° (mod 23) = 4. 

The sender picks r = 5 < gq and computes: 


x =a’ (mod p) 


3° (mod 23) = 13 


The receiver sends t = 15 to the sender and the sender computes: 


r+ st (mod q) 
= (5+ 8 x 15)(mod 11) 
= 125 (mod 11) =4 


y 


Table 5.8 Schnorr’s authentication algorithm 
Preprocessing: 


Choose two primes, p and q, such that qg is a prime factor of p — 1. 
Choose a such that a? = 1 (mod p). 


Key generation: 


Choose a random number s < q (private key) 
Compute 2 = a~* (mod p) (public key) 


User A User B 

Choose a random number r < q 

Compute x =a’ (mod p) Pick a random number ¢ such that 0 <t < 2”-—1 
<_ Send ¢ to user A 


Compute y =r + st (mod q) 
Send y to user B > Verify that x = a’A‘ (mod p) 
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Figure 5.7 Schnorr’s authentication scheme. 


To verify x =a’ - A‘ (mod p) = 13, compute: 
x = (34)(4) (mod 23) 
= 12 x 3 (mod 23) = 13 


Since a’ (mod p) = a’! (mod p) = 13, the authentication is accepted. 


5.4.2 Schnorr’s Signature Algorithm 

For a digital signature, user A concatenates the message m and x and computes the 
hash code: 

h= H(m||x) 


User A sends the signature (h, y) to user B. User B computes z = a’A" (mod p) and 
confirms whether hashing the concatenation of m and z yields: 


h' = H(mllz) 


If h =h’, then user B accepts the signature as valid. 

For the same level of security, Schnorr’s signature algorithms are shorter than RSA 
ones. Also, Schnorr’s signatures are much shorter than ElGamal signatures. Figure 5.8 
and Table 5.9 illustrate Schnorr’s signature algorithm. 
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Figure 5.8 Schnorr’s signature scheme. 


Table 5.9 Schnorr’s signature algorithm 


Preprocessing stage and the two key pair are the same. 
User A User B 


Choose r < g (a random number) 

Compute x = a” (mod p) 

Concatenate m and x, i.e. m||x and hash 

such that h = H(m||x) 

Compute y=r-+sh (mod q) 

Send the signature (h, y) to user B > Compute z = a’A" (mod p) 
Concatenate m and z and hash: 
h' = H(ml|lz) 
If the two hash values match (h = h’), 
then user B accepts the 
signature as valid 


Example 5.12 First choose two primes p = 29 and g =7 such that g|p — 1, i.e. g is 
a prime factor of p—1. Determine a =7 in order to meet the requirement of a? = 1 
(mod p) such that 77 = 823543 = 1 (mod 29). Pick a private key s = 4 such that s < q 
and compute the public key as follows: 


24 =a~ (mod p) 
= 7~* (mod 29) = 24 
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User A: 
Choose a random number r = 5 < q and then compute: 


x =a’ (mod p) 

= 7° (mod 29) = 16 
Concatenate m and x and hash m||x such that 
h= H(m|lx) = H(12345|/16) 


where the message m = 12345 is assumed., To produce the message digest h = H(m||x), 
use the Secure Hash Algorithm (SHA) which is closely modelled on MD4. Utilising SHA 
for h yields a 160-bit message digest as the output, as follows: 


h = H (m||x) (mod g) = H (12 345||16) (mod 7) 
= al1784b83ea003cd6649 1c7e1de07296d9d9242c (hexadecimal) 
= 919671992759145855242593220263016201851705566252 
(mod 7) (decimal) 
=5 
User A computes y =r + sh (mod q): 
y =(5+4 x 5) (mod 7) = 25 (mod 7) = 4 
Send signature (h, y) = (5, 4) to user B. User B first computes: 
z =a? -" (mod p) 
= 7* x 24° (mod 29) 
= (23 x 7) (mod 29) 
= 16 
Concatenate m = 12345 and z and hash it as follows: 
h' = H(mllz) (mod q) 
= H(12345||16) (mod 7) 
=5 


which is identical to h. Therefore, user B accepts the signature as valid because h = h’. 

The next example demonstrates how to solve the problem, making use of the MD5 
algorithm in order to compute the 128-bit message digest. The source code of the MD5 
program can be obtained from ftp.funet.fi:/pub/crypt/hash/mds/md5. 


Example 5.13 If two primes p = 23 and q = 11 are given, then a = 9 is determined. 
Choose a private key s = 4, a random number r = 7 and the message m = 135. 
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Key generation 
Private key: s = 4 
Public key:4 = a~* (mod p) 
= 9-4 (mod 23) =4 
User A 
Compute x =a’ (mod p) 
= 9’ (mod 23) =4 

Using the MD5 algorithm, compute the message digest: 

h = H(m\|x) (mod q) 
= H(135||4) (mod 11) 

h = af 4732711661056eadbf 798ba191272a (hexadecimal) 
= 232984575419504758889249578349365372714 (mod 11) 
=0 

Using h = 0, y =r-+sh (mod g) becomes y = 7 (mod 11). 

Send the signature (h, y) = (0, 7) to user B. 


User B 
When user B receives the signature (h, y), compute: 


z=aa" (mod p) 

= 9! (mod 23) =4 
Applying MDS to h’ = H(ml|z) (mod gq) = H(135||4) (mod 11), we have 
h' = af 4732711661056eadbf 798ba191272a 


Thus, user B confirms verification of h’ (mod 11) = h (mod 11) = 0. 


5.5 Digital Signature Algorithm 


In 1991 The National Institute of Standards and Technology (NIST) proposed the Dig- 
ital Signature Algorithm (DSA) for federal digital signature applications. The proposed 
new Digital Signature Standard (DSS) uses a public-key signature scheme to verify to a 
recipient the integrity of data received and the identity of the sender of the data. 

DSA provides smartcard applications for digital signature. Key generation in DSA is 
faster than in RSA. Signature generation has the same level of speed as RSA, but signature 
verification is much slower than RSA. 

Many software companies, such as IBM, Microsoft, Novell and Apple, that have 
already licenced the RSA algorithm, protested against the DSS. Many companies wanted 
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NIST to adopt ISO/IEC 9796 for use instead of RSA as the international digital signature 
standard. 

The DSA is based on the difficulty of computing discrete logarithms, and originated 
from schemes presented by ElGamal and Schnorr. The public key consists of three param- 
eters, p,q and g, and is common to a group of users. Choose q of a 160-bit prime number 
and select a prime number p with 512 < p < 1024 bits such that qg is a prime factor of 
p — 1. Next, choose g > 1 to be of the form h’?~-)/7 (mod p) such that h’ is an integer 
between | and p— 1. 

With these three numbers, each user chooses a private key x in the range 1 < x <q —1 
and the public key y is computed from x as y = g* (mod p). Recall that determining x 
is computationally impossible because the discrete logarithm of y to the base g (mod p) 
is difficult to calculate. 

To sign a message m, the sender computes two parameters, r and s, which are functions 
of (p,q, g and x), the message digest H(m), and a random number k < q. At the receiver, 
verification is performed as shown in Table 5.10. The receiver generates a quantity v that 
is a function of parameters (x, y,r,s~'! and H(m)). 

When a one-way hash function H operates on a message m of any length, a fixed- 
length message digest (hash code) h can be produced such that h = H(m). The message 
digest h to the DSA input computes the signature for the message m. Signing the message 
digest rather than the message itself often improves the efficiency of the signature process, 
because the message digest / is usually much smaller than the message m. The SHA is 
called secure because it is designed to be computationally impossible to recover a message 
corresponding to a given message digest. Any change to a message in transit will result 
in a different message digest, and the signature will fail to verify. The structure of the 
DSA algorithm is illustrated in Figure 5.9. 


Example 5.14 Choose p = 23 and g = 11 such that q is a prime factor of p—1. 
Choose h’ = 16 < p—1 such that g = 16° (mod 23) = 3 > 1. Choose the private key 
x = 7 <q and compute the public key y = g* (mod p) = 3’ (mod 23) =2. 


Sender: (signing) 
Choose k = 5 such that k < g = 11 and compute the signatures (r,s) as follows: 


r = (g* mod p) (mod q) 
= (3° mod 23) (mod 11) = 13 (mod 11) = 2 
Assume that 4 = H(m) = 10 and compute: 
s =k"! (h+xr) (mod q) 
= 5°! (10+7 x 2) (mod 11) = (9 x 24) (mod 11) = 216 (mod 11) =7 
where the multiplicative inverse k! is: 
k-k~! =1 (mod q) 
5k~' = 1 (mod 11) from which k~! = 9 
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Table 5.10 DSA signatures 


Key pair generation: 


p: a prime number between 512 to 1024 bits long 
q: a prime factor of p — 1, 160 bits long 

g =h’?-Y/4 (mod p) > 1, and h’ < p— 1 

(p,q and g): public parameters 

x <q: the private key, 160 bits long 

y = g* (mod p): the public key, 160 bits long 


Signing process (sender): 


k <q: a random number 

r = (g* mod p) (mod q) 

s =k"! (h+xr) (mod q), h = H(m) is a one-way hash function of the 
message m. 

(r, 5): signature 


Verifying signature (receiver): 


w =s—!' (mod q) 

ul =h x w (mod q) 

u2=r xX w (mod q) 

v = (g"'y"? (mod p)) (mod q) 


If v =r, then the signature is verified. 
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Figure 5.9 DSA digital signature scheme. 
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Receiver: (verifying) 

Compute: 

w =s_! (mod q) 
=7 ! (mod 11) =8 

ul = (h x w) (mod q) 
= (10 x 8) (mod 11) =3 

u2 = (r x w) (mod q) 
= (2 x 8) (mod 11) =5 

v = ((g"! x y"’) mod p) (mod q) 
= ((3° x 2°) mod 23) (mod 11) 
= (864 (mod 23)) (mod 11) = 13 (mod 11) = 2 


Since v = r = 2, the signature is verified. 


5.6 The Elliptic Curve Cryptosystem (ECC) 


The Elliptic Curve Cryptosystem (ECC) was introduced by Neal Koblity and Victor Miller 
in 1985. The elliptic curve discrete logarithm problem appears to be substantially more dif- 
ficult than the existing discrete logarithm problem. Considering they have equal levels of 
security, ECC uses smaller parameters than the conventional discrete logarithm systems. 

In this section we first present the concept of an elliptic curve and then discuss its 
applications to existing public-key algorithms. Finally, we will look at cryptographic 
algorithms with elliptic curves over the prime or finite fields. 


5.6.1 Elliptic Curves 


Elliptic curves (ECs) have been studied for many years. Elliptic curves over the prime 
field Z, or the finite field GF(2”) are particularly interesting because they provide a way of 
constructing cryptographic algorithms. ECs have the potential to provide faster public-key 
cryptosystem with smaller key sizes. 


Elliptic curves over prime field Z, 


Figure 5.10 shows the elliptic curve y* = x? + ax + b defined over Z, where a, b € Zp - Zp 
is called a prime field if and only if p > 3 is an odd prime. An elliptic curve (EC) can 
be made into an abelian group with all points on an EC, including the point at infinity 
O under the condition of 4a* + 27b* 4 0 (mod p). If two distinct points P(x), y,) and 
Q(x2, y2) are on an elliptic curve, the third point R is defined as P+ Q = R(x3, y3) 
(see Figure 5.10). The third point R is defined as follows: first draw a line through P 
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Figure 5.10 An elliptic curve. 


and Q, find the intersection point —R on the elliptic curve, and finally determine the 
reflection point R with respect to the x-axis, which is the sum of P and Q. If P(x, y) 
is a point on an elliptic curve (EC), then P + P = R(x3, y3) (double of P) is defined 
as follows: first draw a tangent line to the elliptic curve at P. This tangent line will 
intersect the EC at a second point (—R). Then R(x3, y3) is the reflection point of —R 
with respect to the x-axis, as depicted in Figure 5.11. If P(x, y) € O, it is defined as 
—P(x,—y). Hence if Q = —P, it satisfies P + Q = O. Since all arithmetic operations 
are written additively, P + P = 2P = O because slope {P(x;, 0)} L x-axis when y; = 0. 
Subsequently, 3P =2P+P=P,4P=2P4+2P=0,5P=4P+P=P.,..., ete. 

If the points on an elliptic curve y? = x*+ax +b over Z, are represented by the 
points P(x1, y,), Q(x2, y2) and R(x3, y3) = P + Q, the following theorems will hold: 


1. When P 4 Q, x3 =a? — x1 — x2, y3 = —yy +a (x) — x3) when @ = (y2 — y1)/Q2 — 
x,). Consider the linear curve y = ax + i passing through the points P and Q. Then 
a and A are written as a = (y2 — y;)/(x2 —x;) and A= y; — ax, respectively. If 
the point (x, y) = (x,ax +4) on PQ meets the condition to be on EC, it should be 
(ax +A)? =x? +ax+b or x? —a?x? + (a — 20d)x +b —A* =0 from which we 
can obtain x; + x. +x; =a? with due regard to the relation between roots and coef- 
ficients. Thus it proves to be: 
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Figure 5.11 The doubling of an elliptic curve point. 
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When P = Q (i.e. 2P(x3, y3)), x3 = B? — 2x1, y3 = —yi + B(x — x3) when B = 


(3xf + a)/(2y1). 
Using y* = x° + ax +b, compute the slope at P. 


d 
2y (2) =3x* +4 
dx 


dy 3x7 +a 
r — = — B 
dx 2y 











3x2 +a\" 3x? 
n= (3%) — 2x and went (AE) oy 


2y1 2y1 


Figure 5.11 shows a geometric description of the doubling of an EC point 2P = 


R(x3, y3)). 
When P = —Q, it is obvious that P+ Q = O. 
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Example 5.15 Let p = 17. Choose a = 1 and b =5 such that the elliptic curve over 
Z17 becomes y? = x* +x +5 (mod 17). 


4a? + 27b? = 4 + 675 = 679 = 16 (mod 17) 
Hence the given equation is indeed an elliptic curve. 


1. Let P = (3, 1) and Q = (8, 10) be two points on the EC. Then P + Q = R(x3, y3) is 
computed as follows: 


P+Q= (3,1)+ (8, 10) 
(B=) 
x3 = | —— ] -x,-x 
X2— X1 
9\2 
={-] -—3-8 
(5) 
Since 9 x 5~! (mod 17) = 9 x 7 (mod 17) = 12, it gives 
x3 = (12? — 3 — 8) (mod 17) = 14 
9 
yz3=—-1+ (2) x 3 - 14) =—-1+4+12 x (-11) = —133 (mod 17) = 3 
Hence P+ Q = R(14, 3). 


2. Let P = (3,1). Then 2P = P+ P = (x3, y3) is computed as follows: 


2P = 3,14+ 3,1) 





= 147 —-6 = 196 — 6 = 190(mod 17) = 3 
and 
3x2 +a 
n=-n+( L ) 1-9 
2y1 
= —1+ 14(3 — 3) = —1(mod 17) = 16 





Hence 2P = (3, 16). 

If P is an odd prime, 0 < z < p, and gcd(z, p) = 1, then z is called a quadratic residue 
modulo p if and only if y* = z (mod p) has a solution for some y; otherwise z is called 
a quadratic nonresidue. 

For example, the quadratic residues modulo 13 are determined as follows: 


Z*, = {1,2,3,..., 12} 
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The square of the integers in Z}, for modulo 13 is computed as: 
{1727 3? ng AE, 127} (od 13) = [1-3 4,910.12} 


Hence the quadratic nonresidues modulo 13 are {2,5, 6,7, 8, 11}. Now you can see that 
the set Z7, = {1,2,3,..., 12} is equally divided into quadratic residues and nonresidues. 
In general, there are precisely (p — 1)/2 quadratic residues and (p — 1)/2 quadratic non- 
residues of p. 


Euler’s criterion 


Let p be an odd prime and gced(z, p) = 1. Using Fermat’s theorem z?~! = 1 (mod p), or 
z?-! _ 1 =0 (mod p), it gives (z?~-)/? — 1)(z-/? + 1) = 0 (mod p) from which z is 
a quadratic residue of p if z“°~)/* = 1 (mod p); and a quadratic nonresidue of p if and 
only if z?-)/? = —1 (mod p). 


Legendre symbol (z/p) 


If p > 2 is a prime, 0 < z < p, and gcd(z, p) = 1, the Legendre symbol (z/p) is a char- 
acteristic function of the set of quadratic residues modulo p as follows: 


(<) = {! if z is a quadratic residue of p 


D —1 if z is a quadratic nonresidue of p 


Example 5.16 Let p = 17,a = 6 and b =5S. Then the elliptic curve (EC) is defined as 
y? = x3 + 6x +5 over Z17. Note that 4a? + 27b? = 1539 (mod 17) = 9, so the given EC 
is indeed an elliptic curve. The points in EC(Zj7) are {0} U {(2, 5), (2, 12),..., (16, 10)}. 
Let’s first determine the points on EC. Compute y* = x* + 6x +5 (mod 17) for each 
possible x € Z17. It will be necessary to check whether or not z = x? + 6x +5 (mod 17) 
is a quadratic residue for a given value of x. If z is a quadratic residue, then y can be 
computed by solving y* = z (mod 17). 

For x = 0, then z= 5. Hence 5'?~!/* (mod z) = 5° (mod 17) = 16 (mod 17) = —1 
(quadratic nonresidue) 
For x = 1, then z = 12. Hence 12° (mod 17) = 16 (mod 17) = —1 (quadratic nonresidue) 
For x = 2, then z = 25. Hence 25° (mod 17) = 1 (quadratic residue) 

Then, solving y* = 25 (mod 17), we obtain y = 5 and y = 12. 
Two points on the elliptic curve are found as (x, y): (2, 5) and (2, 12). 
Check: 57 (mod 17) = 25 (mod 17) = 8 and 12? (mod 17) = 144 (mod 17) = 8. 
Hence, y = 5 and y = 12 are checked as two solutions. 

Continuing in this way, the quadratic residues and the remaining points on the EC can 
be computed as shown in Table 5.11. 
Let EC be an elliptic curve over Z,. Hasse states that the number of points on an ellip- 
tic curve, including the point at infinity O, is #EC(Z,) = p+1-—t where |t| < 2,/p. 
#EC(Z,) is called the order of EC and f is called the trace of EC. 
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Table 5.11 Quadratic residues and points on EC y? = x7 +6x+ 
5 =z over Z17 


x z (mod 17) Quadratic residue Point (x, y) on EC 


ZP-D/2 =] 
or (z/p) = 1 
0 5 —l — 
1 12 —1 = 
2 8 1 (2, 5) (2, 12) 
3 16 1 (3, 4) (3, 13) 
4 8 1 (4, 5) (4, 12) 
5 7 —1 = 
6 2 1 (6, 6) (6, 11) 
7 16 1 (7, 4) (7, 13) 
8 4 1 (8, 2) (8, 15) 
9 6 —1 — 
10 11 —] = 
11 8 1 (11, 2) (11, 15) 
12 3 -1 = 
13 2 1 (13, 6) (13, 11) 
14 11 —] — 
15 2 1 (15, 6) (15, 11) 


16 15 1 (16, 7) (16, 10) 


Example 5.17 Let EC be the elliptic curve y* = x* + x +6 over Zj;. All points on EC 
can be determined as: 


EC(Zi1) = {(2, 4), 2, 7), G, 5), 3, 6), GS, 2), G, 9), 
(7, 2), (7, 9), (8, 3), (8, 8), (10, 2), (10, 9)} U {0} 


Any point other than the point at infinity can be a generator G of EC. If we pick G = (8, 3) 
as the generator, the multiples of G can be computed as follows: 
When P = QO, 2G = (8,3) + (8, 3). Using x3 = B? — 2x, and y3 = —y, + B(x; — x3) 





3 2. 
where 6 = + aes (mod p), 2G(x3, y3) is computed as follows: 
J 
3x 8?+1 
Since B = ~~~ (mod 11) = 1, x3 = 1? — 16 (mod 11) =7 
x 


and y3 = —3+ 1(8 — 7) (mod 11) = 9. 


Hence 2G = (7,9). 

For 3G = 2G + G = (7, 9) + (8, 3), it may be expressed as P = 2G and Q = G. Since 
P # Q, we use x3 = B? — x; — x2 and y3 = —y, + B(x; — x3) where B = (y2 — y1)/(x2 — 
x,). Compute 6 first as: B = = (mod 11) =5. Thus, x; = 5? — 7-8 (mod 11) = 10 
and y3 = —9+5 (7— 10) (mod 11) = 9. Hence 3G = (10, 9). 
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Continuing in this way, the remaining multiples are computed as shown below: 


G=(8,3) 2G=(7,9) 3G=(10,9) 4G = (2,4) 5G =(5,2) 6G=@,6) 
7G = (3,5) 8G=(5,9) 9G=(2,7) 10G=(10,2) I1G=(7,2) 12G= (8,8) 


The generator G = (8, 3) is called a primitive element that generates the multiples. 


Elliptic curve over finite field GF(2”) 
An elliptic curve over GF(2”) is defined by the following equation: 
yr tay =x tax? +b 


where a,b € GF(2”) and b #0. The set of EC over GF(2”) consists of all points 
(x, y), x, y € GF(2”), that satisfy the above defining equation, together with the point 
of infinite O. 


Addition 


Adding points on an EC over GF(2”) will give a third EC point. The set of EC points 
forms a group with O (point of infinity) serving as its identity. The algebraic formula for 
the sum of two points and the doubling point are defined as follows: 


1. If P € EC(GF(2”)), then P+(—P) =O, where P = (x, y) and -P=(x,x+y) 
are indeed the points on the EC. 

2. If P and Q (but P ¥ Q)are the points on the EC(GF(2”)), then P + Q = P(x, v1) + 
O(xX, yo) => R(x, y3), where x3 Na +A+ Xj +%x2+a and ¥3= A(x} + x3) + x34 
yi, where A = (y1 + y2)/@1 + x2). 

3. If P is a point on the EC (GF(2”)), but (P 4 —P), then the point of doubling is 
2P = R(x3, y3), where 


b 
maatt panda aft (nt 2) abn 
x) X{ 


Example 5.18 Consider GF(2*) whose primitive polynomial is p(x) = x4+x+1 of 
degree 4. If a is a root of p(x), then the field elements of GF(2*) generated by p(x) 
are shown in Table 5.12. Since p(w) =a++a+1=0, ie. at =a+1, the field ele- 
ments of GF(2*) are expressed by four-tuple vectors such as 1 = (1000), a = (0100), a? = 
(0010),..., a! = (1001). 

Choosing a = a* and b = 1, the EC equation over GF(2*) becomes 


ytxy =xrtatx +1 
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Table 5.12 Field elements of GF(2*) using at =a+4+1 


avj,0<i< 14 Polynomial expression Vector form 

a 1 1 0 0 0 
a! a 0 1 0 0 
a oe 0 0 1 0 
a a 0 0 0 1 
a‘ l+a 1 1 0 0 
a ate? 0 1 1 0 
a 2+ 0 0 1 1 
a! lt+a+ a 1 1 0 1 
a’ 1+ a? 1 0 1 0 
a? a+ a 0 1 0 1 
q!0 lt+a+a? 1 1 1 0 
q!! at+e+e 0 1 1 1 
a!2 ltat+a?+a3 1 1 1 1 
a3 1+ +3 1 0 1 1 
a!4 I+ +03 1 0 0 1 


Check whether one element (a3, a) satisfies the EC equation over GF(2*). 
(a8)? + (a*)(a®) = (2°)? + (a3)? + 1 
gi hegre 
(0100) + (0111) = (0101) + (1110) + (1000) 
(0011) = (0011) 
Thus, the points on the EC(GF(2*)) are O (point at infinity) and the following 15 elements: 


(0, 1) (1, @°) (1, a!) (a3, a8), (a3, a!3) 
(a, a) (a, a!!) (a, a’) (a, a!*) (2°, @!0) 
(a, a!3) (a!9, a) (q@!°, a’) (a!?, 0), (a!?, a!?) 


Example 5.19 Consider the elliptic curve y* + xy = x3 +a4x? +1 over GF(2+) used 
in Example 5.18. Then the point addition P(a#®, w®) + Q(a3, a!) = R(x3, y3) is computed 
as follows: 
aoc 

Since A= eae =a, we have 4=MW+A4x,4+m+a=e0+a+a%+o7H+ 
o* = 1 and yg =A +43) +3934 91 =a(a°+1)+14+a8 =a(a!3) +a? =a 
Hence P + Q = R(1, a!°). 

Next, the point-doubling problem of 2P = P + P = R(x3, y3) is considered as shown 
below: 
=a'?+q3=a! (Take the inverse of a’ to be a! = 


b 
2252 12 
a ia i ae To 


. 1 
q 7 iths (mod15) _ 
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and y3 =7+(n+2) atx 
xX] 


so 19. 6, & 10 10 

=a~+itarc+ ae a‘*+a 

=aPt+qB+ql = (1010) = a8 
Hence 2P = R(x3, y3) = (a!°, a) 


5.6.2 Elliptic Curve Cryptosystem Applied to the ElGamal 
Algorithm 


As an application problem to ECC, consider the ElGamal public-key cryptosystem based 
on the elliptic curve defined over the prime field Z,. The ElGamal crypto-algorithm is 
based on the discrete logarithm problem. Referring to Table 5.5 for the ElGamal encryp- 
tion algorithm, choose a prime p such that the discrete logarithm problem in Z, is 
intractable, and let w be a primitive element of Z>. The values of p,a and y are public, 
and x is secret. 


y =a“ (mod p) 


Choose a random number k such that gcd(k, p — 1) = 1. Then the encryption process of 
the message m,0 <m < p — 1, is accomplished by the following pair (r,s): 


r =a‘ (mod DP) 


Ss =(m (mod p — 1)) (y* (mod p)) 


For r,s € Z>, the decryption is defined as: 
S 

m = —(mod p) 
r* 


Elliptic curve cryptosystem by the ElGamal algorithm 


User A User B 
Let X be the plaintext and k a <_ Generate B’s private key eg and a 
random number. Choose X and k public base point G. The public key 
is represented by (G, egG) 
Compute Y = (x, y) wherex =kG —> Receive 
and y = X + k(egG) Y= (x, y) = (kG, X + k(egG)) 
Send Y to user B Decryption yields X = y — egx 


Many public-key algorithms, such as Diffie-Hellman, ElGamal and Schnorr, can be 
implemented in elliptic curves over finite fields. 


Example 5.20 Suppose user B generates a private key eg = 10 and picks a base point 
G = (8,3) as a generator on the EC y? =x*>+x+6 over Z,,. Then B’s public key 
becomes (G, egG) = ((8, 3), 10(8, 3)) = ((8, 3), (10, 2)). 
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User A wishes to send the plaintext X = (2, 4) and chooses a random number k = 5. 
Compute the ciphertext Y = (x, y), x, ye EC 


Where x = kG = 5(8, 3) = (5,2), 
y = X+k(egG) = (2, 4) + 5(10, 2) 
= 2,4)+ (7,2) = (7, 9) 
Send Y = (x, y) = ((5, 2), (7,9) to B. 


B receives Y and decrypts it as follows: 
X =y— epx 
= (7,9) — 1065, 2) = (7,9) + (7,9) = 2,4) 


Thus, the correct plaintext X is recovered by decryption. 


5.6.3 Elliptic Curve Digital Signature Algorithm 


The Elliptic Curve Digital Signature Algorithm (ECDSA) was first proposed by Scott 
Vanstone in 1992 and was accepted in 1999 as an ANSI standard and in 2000 as IEEE and 
NIST standards. ECDSA is the elliptic curve analogue of DSA (see Section 5.5). Elliptic 
Curve Cryptosystems (ECCs) are viewed as elliptic curve analogues to the conventional 
discrete logarithm cryptosystems in which the subgroup of Z> is replaced by the group of 
points on an elliptic curve over a finite field. The security of elliptic curve cryptosystems is 
based on the computational intractability of the elliptic curve discrete logarithm problem. 
The ECDSA signature and verification algorithms are presented in this section. 

Procedures for generating and verifying signatures using ECDSA are described in 
the following. 


Domain parameters 


The domain parameters for ECDSA consist of a proper elliptic curve, EC, defined over a 
prime field Z, of characteristic p, or an extension field GF(2”) of characteristic 2 and a 
base point G €¢ EC(Z,). The order of the underline finite field Z, or GF(2”) is p or 2”. 
A set of EC domain parameters is comprised of: 

D=(q, FR, a,b, G,n, A) 


where q:A field size eitherp or 2” 
FR: Field representation used for elements of Z, or GF(2”") 
a,b € Z, or GF(2"): Two field elements that define an elliptic 
curve EC: 


y=x+ax?+b over Zp, p > 3 
y? +xy =x? +.ax? +b over GF(2”), p = 2” 


G: The base point,G < EC (Z, or GF(2”)) 
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n: The order of the point G, with n > 2!6° (ANSI X.9.62) and n > 4./¢ 
A: The cofactor is defined as A = #EC(Z, or GF(2”))/n. 


Generation and verification of a random elliptic curve 


The method for verifiably generating an elliptic curve at random is presented here to give 
some assurance regarding the possible future discovery of new and rare classes of weak 
elliptic curves. 


The Case Zp 

Input: A field size p (an odd prime) 

Output: A bit string E of length g > 160 bits and field elements a, b € Z, that define an 
elliptic curve EC: y? = x3 + ax? +b over Zp. 


ALGORITHM 


1. Choose an arbitrary bit string E of length g > 160 bits. 

2. Compute the hash code h = SHA-1(E) and let co be the bit stream of length v bits 
obtained by taking the v rightmost bits of h, where v = t — 160 x s, t = [log, 5] 
and s = |(t — 1)/160]. 


3. Wo is the v-bit stream taken by setting the leftmost bit of co to zero. 
4. The integer z whose binary expansion is the g-bit stream E. 
5. Fori from | to s: Let s; be the g-bit string of the integer (z +i) mod 2%. Compute 


W; = SHA-1(s;). 
6. W is the bit string obtained by concatenation: W = Wo||W) ||... || Ws. 
7. r is the integer whose binary expansion is W. 
8. Ifr=0 or 4r + 27 = 0 (mod p), then go to step 1. 
9. Choose a £ 0, b £0 € Z, such that rb? =a? (mod p). If this condition is met, then 
accept; otherwise reject. 
10. Output (E, a, b). 
11. If the bit string is W’ = Wo||W\||...||W; and r’ is the integer whose binary expansion 
is given by W’, then the condition for acceptance is r’b? = a> (mod p). Other- 
wise, reject. 


The Case GF(2”) 

Where GF(2”), s = |(m — 1)/160] and v = m — 160 x s are used. 

Input: A field size 2” 

Output: A bit string E of length g > 160 bits and field elements a, b € GF(2”) that define 
an elliptic curve EC: y? + xy = x? + ax? + b over GF(2”). 


ALGORITHM 


1. Choose an arbitrary bit string E of length g > 160 bits. 
Compute the hash code h = SHA-1(E) and let bo be the bit string of length v bits 
obtained by taking the v rightmost bits of h. 

3. Let z be the integer whose binary expansion is the g-bit stream E. 

4. Fori from | to s: Let s; be the g-bit string of the integer (z + 7) mod 2%. Compute 
b; = SHA-1(s;). 
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Let b be the field element obtained by concatenation as b = bo||D,|| .. . ||Ds. 
If b = 0, then go to step 1. 

Let a be an arbitrary element of GF(2”). 

Output (E, a, b). 

Let b’ be the field element such that b’ = bo||b,|| .. . ||Ds. 

If b' = b then accept. Otherwise, reject. 


POCO 


— 


Key pair generation 


An ECDSA key pair is associated with a particular set of EC domain parameters D = 
(q, FR, a, b, G,n, d) that must be valid prior to key generation. 

User A selects a random integer d for 1 < d <n —1 and computes Q = dG where Q 
is A’s public key and d is A’s private key. 


e Choose Q # O. 

e Check whether a public key Q = (xg, yg) is properly represented by the elements of 
Zp over (O, p — 1) and m-bit string over GF(2”) of 2”. 

e Check that Q lies on the elliptic curve defined by a and b. 

e Check that nQ = O. 

e If any check fails, then Q is invalid; otherwise Q is valid. 


5.6.4 ECDSA Signature Computation 


In 2001, Johnson, Menezes and Vanstone jointly presented a paper on the ECDSA. The 
ECDSA algorithms on signature and verification are briefly introduced in this section. 


User A: signature 


To sign a message m, user A with EC domain parameters D and the key pair (d, Q) will 
take the following steps for ECDSA signature generation. 

Select a random integer k, 1 <k <n-—1. 

Compute kQ = (x;, yi) and convert x; to an integer x}. 

Compute the following steps: 


e r=x; (mod n). If r =0, then go to the initial step. 
e k~' (mod n); and h = SHA-1(m) of m and convert this bit string to an integer e. 


Compute s = k~'(e + dr) (mod n). If s = 0, then go to the initial step. 
A’s signature for the message m is (r,s). 


User B: verification 


To verify A’s signature (r,s) on m, the user B must obtain an authentic copy of A’s 
domain parameters D and associated public key Q. Verify that r and s integers over 
[1,n—1]. 
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Compute the message digest h = SHA-1(m) of the message m and convert this bit 
string to an integer e. 
Compute the following steps: 


e w=s! (mod n) 
© u, =ew (mod n) and vu. =rw (mod n) 
e X=u,G4+uwQ. 


If X = O, reject the signature. Otherwise, convert the X coordinate x; of x to an integer 
x}, and compute v = x; (mod n). Finally, accept the signature if and only if v =r. 


Example 5.21. User A uses the EC y* = x*+.x+ 6 over Z;;. Choose the key pair 
(d, Q) in which d = 2 (A’s private key), Q = (7, 9) (A’s public key) and k = 5 (a random 
integer). G = (8, 3). Compute the following steps: 

kQ = 5(7, 9) = (10, 2) from which r = x; = 10. 

k-! =8 is the multiplicative inverse of k = 5 (mod 13). 

Suppose the message digest h = SHA-1(m) = 8 is an converted integer e. 

Compute s = k~'(e + dr) (mod13) 

= 8(8 + 2 x 10) (mod 13) = 8(28) (mod 13) = 3 
Thus, A’s signature for m is (r, s) = (10, 3). 


To verify A’s signature (r,s) on m, the following computations are required: 
w =s !=37! (mod 13) =9 
u, = ew (mod 13) = 8 x 9 (mod 13) =7 
uz = rw (mod 13) = 10 x 9 (mod 13) = 12 
X =ujG+u2Q = 7(8, 3) + 12(7, 2) = (3,5) + (2, 7) = C10, 9) 
Since v = 10 =r, the signature is accepted. 
Section 5.6 has covered the conceptual, but unified, presentation of the elliptic curve 


cryptosystems. It should be a helpful guide for the beginner to understand what the ECC 
algorithms are all about. 


6 


Public-key Infrastructure 


This chapter presents the profiles related to public-key Infrastructure (PKI) for the Internet. 
The PKI manages public keys automatically through the use of public-key certificates. 
It provides a basis for accommodating interoperation between PKI entities. A large-scale 
PKI issues, revokes and manages digital signature public-key certificates to allow distant 
parties to reliably authenticate each other. A sound digital signature PKI should provide 
the basic foundation needed for issuing any kind of public-key certificate. 

The PKI provides a secure binding of public keys and users. The objective is how to 
design an infrastructure that allows users to establish certification paths which contain 
more than one key. Creation of certification paths, commonly called chains of trust, is 
established by Certification Authorities (CAs). A certification path is a sequence of CAs. 
CAs issue, revoke and archive certificates. In the hierarchical model, trust is delegated 
by a CA when it certifies a subordinate CA. Trust delegation starts at a root CA that is 
trusted by every node in the infrastructure. Trust is also established between any two CAs 
in peer relationships (cross-certification). 

The CAs will certify a PKI entity’s identity (a unique name) and that identity’s pub- 
lic key. A CA performs user authentication and is responsible for keeping the user’s 
name and the associated public key. Hence, each CA must be a trusted entity, at least to 
the extent described in the Policy Certification Authority (PCA) policies. The CAs will 
need to certify public keys, create certificates, distribute certificates, and generate and 
distribute Certificate Revocation Lists (CRLs). The PCA is a special purpose CA which 
creates a policy-setting responsibility: that is, how the CA’s and PCA’s functions and 
responsibilities are defined and how they interact to determine the nature of the infras- 
tructure. Therefore, PKI tasks are centred on researching and developing these functions, 
responsibilities and interactions. 

This chapter presents the interoperability functional specifications that are carried out 
by CA entities at all levels. It describes what the PAA, PCAs and CAs perform. It 
also describes the role of an Organisational Registration Authority (ORA) that acts an 
intermediary between the CA and a prospective certificate subject. In the long run, the 
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goal of the Internet PKI is to satisfy the requirements of identification, authentication, 
access control and authorisation functions. 


6.1 Internet Publications for Standards 


The Internet Activities Board (IAB) is the body responsible for coordinating Internet 
design, engineering and management. The IAB has two subsidiary task forces: 


e The Internet Engineering Task Force (IETF), which is responsible for short-term engi- 
neering issues including Internet standards. 
e The Internet Research Task Force (IRTF), which is responsible for long-term research. 


The IETF working groups meet three times annually at large conventions to discuss 
standards development, but the development process is conducted primarily via open e- 
mail exchanges. Participants of IETF are individual technical contributors, rather than 
formal organisational representatives. 

The most important series of Internet publications for all standards specifications appear 
in the Internet Request for Comments (RFCs) document series. Anyone interested in 
learning more about current developments on Internet standards can readily track their 
progress via e-mail. Another important series of Internet publications are the Internet 
Drafts. These are working documents prepared by IETF, its working groups, or other 
groups or individuals working on Internet technical topics. Internet Drafts are valid for 
a maximum of six months and may be updated, replaced or rendered obsolete by other 
documents at any time. Specifications that are destined to become Internet standards 
evolve through a set of maturity level as the standards evolve, which has three recognised 
levels: Proposed Standard, Draft Standard and Refined Standard. 

To review the complete listing of current Internet Drafts, Internet standards associated 
with PKI will be briefly summarised in the following. 

A public directory service or repository that can distribute certificates is particularly 
attractive. The X.500 standard specifies the directory service. A comprehensive online 
directory service has been developed through the ISO/ITU standardisation processes. 
These directory standards provide the basis for constructing a multipurpose distributed 
directory service by interconnecting computer systems belonging to service providers, 
governments and private organisations. In this way, the X.500 directory can act as a 
source of information for private people, communications network components or com- 
puter applications. When the X.500 standards were first developed in 1984-1988, the use 
of X.500 directories for distributing public-key certificates was recognised. Therefore, 
the standards include full specifications of data items required for X.500 to fulfil this 
role. Since the X.500 technology is somewhat complex, adoption of X.500 was slower 
than expected until the mid-1990s. Nevertheless, deployment of X.500 within large enter- 
prises is increasing and some organisations are finding this repository a useful means of 
public-key certificate distribution. 

The Internet Lightweight Directory Access Protocol (LDAP) is a protocol which can 
access information stored in a directory, including access to stored public-key certificates. 
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LDAP is an access protocol which is compatible with the X.500 directory standards. 
However, LDAP is much simpler and more effective than the standard X.500 protocols. 

The X.509 certificate format describes the authentication service using the X.500 direc- 
tory. The certificate format specified in the Privacy-Enhanced Mail (PEM) standards is the 
1988 version of the X.509 certificate format. The certificate format specified in the Amer- 
ican National Standards Institute (ANSI) X9.30 standards is based on the 1992 version 
of the X.509 certificate format. The ANSI X9.30 standard requires that the issuer unique 
identifier field be filled in. This field will contain information that allows the private key 
to sign the certificate and be uniquely identified. 

The certificate format used with the Message Security Protocol (MSP) is also based on 
the 1988 X.509 certificate format, but it does not include the issuer unique identifier or 
the subject unique identifier fields that are found in the 1992 version of the X.509 format. 

The ISOMEC/AITU X.509 standard defines a standard CRL format. The X.509 CRL 
format has evolved somewhat since first appearing in 1988. When the extension fields 
were added to the X.509 v3 certificate format, the same type of mechanism was added 
to the CRL to create the X.509 v2 CRL format. Of the various CRL formats studied, 
the PEM CRL format best meets the requirements of the PKI CRL format. ITU-T X.509 
(formerly CCITT X.509) and ANSI X9.30 CRL formats are compared with the PEM 
CRL format to show where they differ. For example, the ANSI X9.30 CRL format is 
based on the PEM format, but the former adds one reason code field to each certificate 
entry within the list of revoked certificates. 

All CAs are assumed to generate CRLs. The CRLs may be generated on a periodic 
basis or every time a certificate revocation occurs. These CRLs will include certificates 
that have been revoked because of key compromises, changes in a user’s affiliation, etc. 
All entities are responsible for requesting the CRLs that they need from the directory, 
but to keep querying the directory is impractical. Any CA which generates a CRL is 
responsible for sending its latest CRL to the directory. However, CRL distribution is 
the biggest cost driver associated with the operation of the PKI. CAs certifying fewer 
users result in much smaller CRLs because each CRL requested carries far less unwanted 
information. The delta CRL indicator is a critical CRL extension that identifies a delta 
CRL. The use of delta CRLs can significantly improve processing time for applications 
that store revocation information in a format other than the CRL structure. This allows 
changes to be added to the local database while ignoring unchanged information that is 
already in the local database. 


6.2 Digital Signing Techniques 


Since user authentication is so important for the PKI environment, it is appropriate to 
discuss the concept of digital signature at an early stage in this chapter. Digital signing 
techniques are employed to provide sender authentication, message integrity and sender 
non-repudiation, provided that private keys are kept secret and the integrity of public keys 
is preserved. Provision of these services is furnished with the proper association between 
the users and their public/private key pairs. 

When two users A and B communicate, they can use their public keys to keep their 
messages confidential. If A wishes to hide the contents of a message to B, A encrypts 
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Figure 6.1 Overall view of a typical digital signature scheme. 


PUBLIC-KEY INFRASTRUCTURE 205 































































































































































































F Session 
A (client) key B (server) 
(Certification Authority) dp (B’s private key) 
en (B’s public key) ' | 
Session |_K > RSA Dc > RSA > Session 
key encryption ' decryption key 
K K 
v : 
Y= Ex(m) H DES Plaintext H (m) 
DES }———>  Ciphertext 1—>} : >| H mh’ 
' decryption m 
a i Hash Message 
m H function digest 
( ) ‘A’s private key) | 
Plaintext ieee Pe okey) ' 
A 1 
m : 
~ | 
One-way 'C h h’ 
function >) hh = Him) Pr pda CA PY ntlayea 
H ‘ ; 
MDS5 Message RSA 7 é No Yes 
digest encryption ! e, (A‘s public key) 
Authentication Authentication 
is verified fails 


(Certification Authority) 


Figure 6.2. Signature and authentication with DES/RSA/MDS5 (compatible with PEM method). 


it using B’s public key. If A wishes to sign a document, he or she must use the private 
key available only to him or her. When B receives a digitally signed message from A, 
B must verify its signature. B needs A’s public key for this verification. A should have 
high confidence in the integrity of that key. 

The scenario of a typical signature scheme is described in Figure 6.1. The following 
example is presented to illustrate one practical system (Figure 6.2) applicable to the digital 
signature computation for user authentication. The combination of SHA-1 (or MD5) and 
RSA provides an effective digital signature scheme. As an alternative, signatures can also 
be generated using DSS/SHA-1. 

For digital signatures, the content of a message m is reduced to a message digest with 
a hash function (such as MDS). An octet string containing the message digest is encrypted 
with the RSA private key of the signer. The message and the encrypted message digest 
are represented together to yield a digital signature. This application is compatible with 
the Privacy-Enhanced Mail (PEM) method. For digital envelopes, the message is first 
encrypted under a DES key with a DES algorithm and then the DES key (message- 
encryption key) is encrypted with the RSA public key of the recipients of the message. 
The encrypted message and the encrypted DES key are represented together to yield a 
digital envelope. This application is also compatible with PEM methods. 


Example 6.1 Utilizing the practical signature/authentication scheme shown in Fig- 
ure 6.2, the analytic solution is as follows: 
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Client A 


1. 


DES encryption of message m: 
The 64-bit message m is 


m = 785ac3a4bd0fel2d 

The 56-bit DES session key K is 

K = ba0c2b3c484ff9 (hexadecimal) 

The 64-bit ciphertext Y (output of 16-round DES) is 
Y = a78791cOc8f0b444 

RSA encryption of K: 

K = 52367725502681081 (decimal) 

Split K into blocks of two digits: 

K = 0523 677255 02 68 1081 


Obtain B’s public key eg = 79 from CA and choose public modulo n = 3337. 
Encrypt every two-bit block of K as follows: 


5” (mod 3337) = 270 
23”° (mod 3337) = 2524 


81”? (mod 3337) = 3198 


Encrypted K = 0270 2524 1479 0285 1773 3139 2753 3269 3198 
This encrypted symmetric key is called the digital envelope. 

Send this encrypted key (digital envelope) K to B. 

Computation of hash code using MDS: 

Compute the hash value h of m: 


h = H(m) = H(785ac3a4bd0 f e12d) 
= 6a26ee0ed9ce3 963 ec8b0f98ebda8476 (hexadecimal) 
h = 1411003032239129071431837477601 18203510 (decimal) 


Choose da = 13 (A’s private key) and compute: 


c= hts 
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Let us break the hash code into two decimal numbers as follows: 


h=1 41 10 03 03 22 39 12 90 71 
43 18 37 47 76 OL 18 20 35 10 


Using da = 13 and n = 851, compute the RSA signature: 
1° (mod 851) = 1 
41° (mod 851) = 545 


103 (mod 851) = 333 

c=h‘t=001 669 084 400 400 091 348 719 157 303 
635 439 333 047 089 O01 439 520 466 084 

Send c to B. 

A->B 


Send (ciphertext Y, encrypted value of K and signed hash code c) to B. 


Server B 


1. 


Decryption of secret session key K: 
Received encryption key K: 


K = 0270 2524 1479 0285 1773 3139 2753 3669 3198 
Choose dg = 1019 (B’s private key) and decrypt K block by block: 


270"! (mod 3337) = 5 
2524!9!9 (mod 3337) = 23 


3198'°! (mod 3337) = 81 
K = 05 23 677255 02 68 1081 
or 
K = 52367725502681081 (decimal) 
= ba0c2b3c484ff9 (hexadecimal) 
Decryption of m using DES: 
Ciphertext Y = a78791cOc8f0b444 
Restored DES key K = ba0c2b3c484//9 
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Using Y and K, the message m can be recreated: 
m = 785ac3a4bd0fel2d 


Computation of hash code and verification of signature: 
Apply MDS algorithm to the restored message in order to compute the hash code: 


h' = H(m) = H(785ac3a4bd0fel2d) 
= 6a26eeVed9ce3 963 ec8b0f9Sebda8476 
Obtain A’s public key e, = 61 from CA and apply ea to the signed hash value c: 


c=001 669 084 400 400 091 348 719 157 303 
635 439 333 047 089 O01 439 520 466 084 


Using ea, compute h = c& as follows: 


1°! (mod 851) = 1 
669°! (mod 851) = 41 


084°! (mod 851) = 10 
Hence, A=1 41 10 03 O03 22 39 12 90 71 
43 18 37 47 76 O1 18 20 35 10 


Convert it to the hexadecimal number: 
h = 6a26ee0ed9ce3 963ec8b0f98ebda8476 
Thus, we can easily check h = h’. 


Digital signing techniques are used in a number of applications. Since digital signa- 


ture technology has grown in demand, its explosive utilisation and development will be 
expected to continue in the future. Several applications are considered in the following. 


Electronic mail security: Electronic mail is needed to sign digitally, especially in 
cases where sensitive information is being transmitted and security services such as 
authentication, integrity and non-repudiation are desired. Signing an e-mail message 
assures all recipients that the sender of the information is the person who he or she 
claims to be, thus authenticating the sender. For example, the DSS is using MOSAIC 
to provide security services for e-mail messages. The DSA has been incorporated into 
MOSAIC and is used to digitally sign e-mails as well as public-key certificates. Pretty 
Good Privacy (PGP) provides security services as well as data integrity services for 
messages and data files by using digital signatures, encryption, compression (zip) and 
radix-64 conversion (ASCII Armor). MIME defines a format for text messages being 
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sent using e-mail. MIME is actually intended to address some of the problems and 
limitations of the use of SMTP. S/MIME is a security enhancement to the MIME 
Internet e-mail format, based on technology from RSA Data Security. Although both 
PGP and S/MIME are on an IETF standards track, it appears likely that PGP will 
remain the choice for personal e-mail security for many users, while S/MIME will 
emerge as the industry standard for commercial and organisational use. 


Financial transactions: This encompasses a number of areas in which money is being 
transferred directly or in exchange for services and goods. One area of financial trans- 
actions which could benefit especially from the use of digital signatures is Electronic 
Funds Transfer (EFT). Digitally signing EFTs are a way of providing security services 
such as authentication, integrity and non-repudiation. 

Secure Electronic Transaction (SET) is the most important protocol relating to e- 
commerce. SET introduced a new concept of digital signature called dual signatures. 
A dual signature is generated by creating the message digest of two messages: order 
digest and payment digest. The SET protocol for payment processing utilises cryptog- 
raphy to provide confidentiality of information, ensure payment integrity and identity 
authentication. 


Electronic filing: Contracting requirements expect certain mandated certificates to be 
submitted from contractors. This requirement is often filed through the submission of a 
written form and usually requires a handwritten signature. If filings are digitally signed 
and electronically filed, digital signatures may be used to replace written signatures 
and to provide authentication and integrity services. 

One of the largest information submission processes is perhaps the payment of taxes 
and the request for tax-related information will require signatures. In fact, the IRS in 
the USA is converting many of these processes electronically and is considering use of 
digital signatures. The IRS has several prototype under development that utilise digital 
signatures generated by using DSA. At present, individuals send their tax forms to 
the IRS in bulk transactions. The IRS will require them to sign the bulk transactions 
digitally to provide added assurances. In future, the electronically generated tax returns 
may be digitally signed. The taxpayer may send the digitally signed electronic form 
to the IRS directly or through a tax accountant or adviser. 


Software protection: Digital signatures are also used to protect software. By signing the 
software, the integrity of the software is assured when it is distributed. The signature 
may be verified when the software is installed to ensure that it was not modified 
during the distribution process. 


Signing and authenticating: Signing is the process of using the sender’s private key 
to encrypt the message digest of a document. Anyone with the sender’s public key 
can decrypt it. A person who wants to sign the data has only to encrypt the message 
digest to ensure that the data originated from the sender. Authentication is provided 
when the sender encrypts the hash value with the sender’s private key. This assures 
the receiver that the message originated from the sender. 

Digital signatures can be used in cryptography-based authentication schemes to 
sign either the message being authenticated or the authentication challenge used in the 


210 INTERNET SECURITY 


scheme. The X.509 strong authentication is an example of an authentication scheme 
that utilises digital signatures. 


Careful selection and appropriate protection of the prime numbers p and q, of the 
primitive element g of p and of the private and public components x and y of each key 
are at the core of security in digital signatures. Therefore, whoever generates these keys 
and their parameters is a vital concern for security. PCAs are responsible for defining 
who should generate these numbers. 

When generating the key for itself and its CA, each PCA needs to specify the acceptable 
algorithms used to generate the prime numbers and parameters. For example, a larger p 
means more security, but requires more computation in the signing and verification steps. 
Thus, the size of p allows a trade-off between security and performance. Each PCA must 
specify the range of p for itself, its CAs and its end users. The range of p is largest for 
the PCA and smallest for the end user. 

One-way hash functions and digital signature algorithms are used to sign certificates 
and CRLs. They are used to identify OIDs for public keys contained in a certificate. 
SHA-1 is the preferred one-way function for use in the Internet PKI. It was developed by 
the US government for use with both the RSA and DSA signature algorithms. However, 
MDS is used in other legacy applications, but it is still reasonable to use MDS to verify 
existing signatures. RSA and DSA are the most popular signature algorithms used in the 
Internet. They combine RSA with either MD5 or SHA-1 one-way hash functions; DSA 
is used in conjunction with the SHA-1 one-way hash function. The signature algorithm 
with the MDS5 and RSA encryption algorithm is defined in PKCS#1 (RFC 2437). The 
signature algorithm with the SHA-1 and RSA encryption algorithms is implemented using 
the padding and encoding mechanisms also described in PKCS#1 (RFC 2437). 


6.3 Functional Roles of PKI Entities 


This section describes the functional roles of the whole entities at all levels within the 
PKI. It also describes how the PAA, PCAs, CAs and ORAs perform. 


6.3.1 Policy Approval Authority 


The PAA is the root of the certificate management infrastructure. This authority is known 
to all entities at all levels in the PKI and creates the overall guidelines that all users, CAs 
and subordinate policy-making authorities must follow. 

The PAA approves policies established on behalf of subclasses of users or communities 
of interest. It is also responsible for supervising other policy-making authorities. 

Figure 6.3 illustrates the PAA functions and their performances. Each PAA performs 
the following functions: 


e Publishes the PAA’s public key. 

e Sets the policies and procedures that entities (PCAs, CAs, ORAs and users) of the 
infrastructure should follow. 

e Sets the policies and procedures, if any, for a new PCA to join the PKI. 
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Figure 6.3 Illustration of PAA functions. 


Carries out identification and authentication of each of its subordinate PCAs and 
national or international infrastructure roots and judges the proper measures to be 
taken for cross-certification. 

Generates certificates of subordinate PCAs and of national or international infrastruc- 
ture roots to be cross-certified. 

Publishes identification and locality of subordinate PCAs such as directory name, 
e-mail address, postal address, phone number, fax number, etc. 

Receives and publishes policies of all subordinate PCAs. 

Specifies information required from subordinate PCAs for a revocation request of the 
PCA’s certificate. 

Receives and authenticates revocation requests concerning certificates it has generated. 
Generates CRLs for all the certificates it has issued. 

Archives certificates, CRLs, audit files and PCA’s policies. 

Deposits the certificates and the CRLs it generates in the directory. 
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6.3.2 Policy Certification Authority 
PCAs are formed by all entities at the second level of the infrastructure. Each PCA 
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describes the users whom it serves. All PCAs have both policy and certification respon- 
sibilities, and must publish their security policies, procedures, legal issues, fees, or any 
other subjects they may consider necessary. For PCAs, the users may be people who are 
affiliated to an organisation or part of a specific community, or a non-human entity. All 


PCA security policies are published and stored on an end user’s local database. Each PCA 


performs the following functions as illustrated in Figure 6.4. 


e Publishes its identification and locality information, such as directory name, e-mail 
address, postal address, phone number, fax number, etc. 


PCA functions 
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Figure 6.4 Illustration of PCA functions. 





Delivery of 
certificates 
and CRLs it 
generates to 
the directory 





PUBLIC-KEY INFRASTRUCTURE 213 


Publishes identification and locality information of its CAs. 
Publishes who it plans to serve. 
Publishes its security policy and procedures which specify the following items: 


— Who generates key variables p, g, g, x and y. 

— The ranges of allowed sizes of p for itself, its CAs and end users. 

— Identification and authentication requirements for the PCA, CAs, ORAs and end 
users. 

— Security controls at the PCA and CA systems that generate certificates and CRLs. 

— Security controls at ORA systems. 

— Security controls for every user’s private key. 

— The frequency of CRL issuance. 

— The constraints it imposes on naming schemes. 

— Audit procedures. 


Carries out identification and authentication of each of its subordinates. 

Generates and manages certificates of subordinate CAs. 

Delivers its own public key and that of PAA to its subordinates. 

Specifies procedures and information required to validate certificate revocation 
requests. 

Receives and authenticates revocation requests concerning certificates it has generated. 
Generates CRLs for all the certificates it has issued. 

Archives certificates, CRLs, audit files, and its signed policy if changed. 

Delivers the certificates and CRLs it generates to the directory. 


6.3.3 Certification Authority 


CAs form the next level below the PCAs. The PKI contains many CAs with no policy- 
making responsibilities. The majority are plain CAs. A few are CAs that are associated 
with PCAs. A CA has any combination of users and ORAs whom it certifies. 

The primary function of the CA is to generate, publish, revoke and archive the public- 
key certificates that bind the user’s identity with the user’s public key. A better and trusted 
way of distributing public keys is to use a CA. CAs are expected to certify the public keys 
of users or of other CAs according to PCA and PAA policies. The CAs ensure that all 
key parameters are in the range specified by the PCA. Thus, CAs either create key pairs 
that satisfy the PCA regulations or they examine user-generated keys to ascertain whether 
they fit within the required range assignment. Referring to Figure 6.5, a CA performs the 
following functions: 


Publishes and augments PCA policy. 

Carries out identification and authentication of each of its subordinates. 

Generates and manages certificates of subordinates. 

Delivers its own public key and its predecessor’s public keys. 

Verifies ORA certification requests. 

Returns certificate creation confirmations or new certificates to requesting ORA. 
Receives and authenticates revocation requests concerning certificates it has generated. 
Generates CRLs for all the certificates it has issued. 
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Figure 6.5 Functions of certificate authority (CA). 


e Archives certificates, CRLs and audit files. 
e Delivers the certificates and the CRLs it generates to the directory. 


6.3.4 Organisational Registration Authority 


The ORA is the interface between a user and a CA. The prime function that an ORA 
performs is user identification and authentication on behalf of a CA and it delivers the 
CA-generated certificate to the end user. After authenticating a user, an ORA transmits a 
signed request for a certificate to the appropriate CA. In response to an ORA request for 
key certification, the CA returns a certificate to the ORA. The ORA passes the certificate 
on to the user. Thus, an ORA’s sole task is to help a user who is far from the user’s CA 
to register with that CA and to obtain a public-key certificate. ORAs must pass certificate 
revocation reports timely and accurately to a CA. In order to verify the signature on the 
information at a future time, ORAs must archive the public key or the certificate associated 
with the signer. The ORA uses a signed message to inform the CA of the need to revoke 
the certificate and to issue a new one. Nowadays RA is preferred for simple use rather 
than ORA. An ORA performs the following functions that are illustrated in Figure 6.6: 


Carries out identification and authentication of users. 
Sends user identification information and the user’s public key to the CA in a signed 
message. 

e Receives and verifies certificate creations or new certificates from the CA. 
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Figure 6.6 Illustration of ORA functions. 


e Delivers the CA’s public key and its predecessor’s public keys as well as the certificate 
to the user if returned. 

e Receives certificate revocation requests, verifies the validity of the requests, and if 
valid, sends the request to the CA. 


6.4 Key Elements for PKI Operations 


This section describes operational concepts of the PKI. In order to comprehend the overall 
PKI operation, one must understand how it conducts its various activities. Each activity 
is broken down into functional steps. The resources required for each functional step 
within each activity must be defined. The resources required for an activity are presented 
in relation to the entities such as User, KG, CA, ORA, PCA or Directory. The steps 
associated with PKI activities are applied to all PKI relationships: User-CA, User—ORA, 
ORA-CA, CA-PCA and PCA-—PAA. 

This section also presents the architectural structures for the PKI certificate manage- 
ment infrastructure. These structures should allow users to establish chains of trust that 
contain no more than a few certificates in length. The functions and responsibilities of the 
CAs and PCAs are briefly reviewed and then how the CAs are interconnected to permit 
establishment of reliable certification paths. Some major activities associated with the PKI 
operations are presented subsequently. 
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6.4.1. Hierarchical Tree Structures 


Chains of trust follow a strict tree hierarchy with a root CA (PAA or PCA) to which all 
trust is referenced. Each CA certifies the public keys of its users and the public key of the 
root CA is distributed to all PKI entities. Thus every entity is linked to the root CA via a 
unique trust path. Figure 6.7 depicts such a tree structure. A number of hierarchies may be 
joined together by cross-certifying their root CA directly or using bridge CAs. Figure 6.8 
illustrates a bridge-type scheme joining a hierarchical tree structure to a mesh structure. 
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Figure 6.7 Hierarchical tree structure. 
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Figure 6.8 A mixed structure using a bridge CA. 
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With a mesh structure, entities may be connected via several chains of trust. PGP is 
a PKI that uses a mesh structure, with every entity acting as their own CA. Gateway 
structures are new structure appearing in VPN applications. In a gateway structure, each 
domain is separated and relies on its gateway to provide external PKI services. Figure 6.9 
depicts a gateway structure with three cross-certified gateways through which the trust of 
the network is channelled. Horizontal structures offer improved robustness to penetration 
by distributing the trust path horizontally. Multiple platform structures can be used to 
introduce redundancy into a PKI structure and thus reduce risk. The public key of each 
user is authenticated in each platform. This is a particular advantage with hierarchical 
structures because it can remove a single point of failure. 


6.4.2 Policy-making Authority 


Chains of trust are based on appropriate policies at all levels in the infrastructure. Asso- 
ciated with the entire PKI is a policy-establishing authority which will create the overall 
guidelines and security policies that all users, CAs and subordinate policy-making author- 
ities must follow. 


e The PAA has the responsibility of supervising other policy-making authorities. The 
PAA will approve policies established on behalf of subclasses of users or of commu- 
nities of interest. 


e The PCAs will create policy details that expand or extend the overall PAA policies. 
Each PCA establishes policy for a single organisation or for a single community of 
interest. PCAs must publish their security policies, procedures, any legal issues, any 
fees or any other subjects that they consider necessary. 


e The CAs are expected to certify the public key of end users or of other CAs in 
accordance with PCA and PAA policies. The CA must ensure that all key parameters 
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Figure 6.9 A gateway structure. 
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are in the range specified by the PCA. Therefore, the CA either creates key pairs 
according to the PCA regulations or examines the user-generated keys to ascertain 
that they satisfy the requirements of the range. A few CAs are associated with PCAs, 
but the majority are plain CAs at all points in the infrastructure. 


e The ORA submits a certificate request on behalf of an authenticated entity. The CA 
returns the signed certificate or an error message to the ORA. The ORA or certificate 
holder requests revocation of a certificate to the issuing CA. The CA responds with 
acceptance or rejection of the revocation request. Certificate Revocation Lists (CRLs) 
contain all revoked certificates that CAs have issued and have not expired. The CA 
returns the signed certificate and its certificate or an error message to the end user. 
The CA posts a new certificate and CRL to the repository. 


6.4.3 Cross-certification 


Suppose the CA has its private/public-key pair and the X.509 certificate issued by the 
CA. If a user knows the CA’s public key, then the user can decrypt the certificate with 
the CA’s public key and verify the X.509 certificate signed by the CA. Thus the user can 
recover his or her public key contained in the X.509 certificate; the user’s public key is 
verified as illustrated in Figure 6.10. 
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KS,,_: User’s private key KS, : CA’s private key 
K, : RSA public key K, _: RSA private key 
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m_ : X.509 certificate ID : UserID 


Figure 6.10 Certification of the user’s public key. 
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The signature algorithm and one-way hash function used to sign a certificate are indi- 
cated by use of an algorithm identifier or OID. The one-way hash functions commonly 
used are SHA-1 and MDS. RSA and DSA are the most popular signature algorithms used 
in the X.509 Public-Key Infrastructure (PKIX). 

Because no one can modify the certificate, it can be placed in a directory without any 
special effort made to protect the certificate. A user can transmit his or her certificate 
directly to other users. In the case when a CA encompasses several users, there must be 
a common trust of that CA. These users’ certificates can be stored in the directory for 
access by all users. 

When all users in a large community subscribe to the same CA, it may not be prac- 
tical for these users. With many users, it is more desirable to have a limited number of 
participating CAs, each CA securely providing its public key to the subordinate users. 
Since the CA signs the certificates, each user must have a copy of the CA’s public key 
to verify signatures. The CA should provide its public key to each user in an absolutely 
secure way so that the user has confidence in the associated certificates. 

Suppose there are two users A and B. A certificate is defined in the following notation: 


X<<A>> 


which means the certificate of user A issued by certification authority X. Consider Fig- 
ure 6.11(a) which depicts a simple example, where X,; and X, represent two CAs. User A 
uses a chain of certificates to obtain user B’s public key. The chain of certificates is 
expressed as: 


X1 KX. > XK BS 
Similarly, user B can obtain A’s public key with the reverse chain such that: 
X.«K Xi > Xi KAD 


This scheme need not be limited to a chain of two certificates. An arbitrarily long path 
of CAs can produce a chain. All the certificates of CAs by CAs need to appear in the 
directory, and the user needs to know how they are linked to follow a path to another 
user’s public-key certificate. X.509 suggests that CAs be arranged in a hierarchy so that 
tracing is straightforward. 

Figure 6.11(b) is an example of such a hierarchy. The connected ellipses circles indi- 
cate the hierarchical relationship among CAs; the associated boxes indicate certificates 
maintained in the directory for each CA entry. Four users are indicated by circles. In this 
example, user A can acquire the following certificates from the directory to establish a 
certification path to user B: 


XKYSYKWPSWKUSUKVSVKB> 


When A has obtained these certificates, A can unwrap the certification path in sequence 
to recover a trusted copy of B’s public key. Using this public key, A can send encrypted 
messages to B. If A wishes to receive encrypted messages back from B, or to sign 
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Figure 6.11 X.509 hierarchical scheme for a chain of certificates. 


messages sent to B, then B will require A’s public key, which can be obtained from the 
following certification path: 


VKUSUKWYeWKYSYKX>XKAD 


B can obtain this set of certificates from the directory, or A can provide them as part 
of the initial message to B. 

CAs may issue certificates to other CAs with appropriate constraints. Each CA deter- 
mines the appropriate constraints for path validation by its users. After obtaining the other 
CA’s public key, the CA generates the certificate and posts it to the repository. 

The procedure for certifying path validation for the PKIX describes the verification 
process for binding both the subject distinguished name and the subject public key. The 
binding is limited by constraints that are specified in the certificates which comprise 
the path. 
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6.4.4 X.500 Distinguished Naming 


X.509 v1 and v2 certificates employ X.500 names exclusively to identify subjects and 
issuers. The information stored in X.500 directories comprises a set of entries. Each entry 
is associated with a person, an organisation or a device which has a distinguished name 
(DN). The directory entry for an object contains values of a set of attributes pertaining 
to that object. For example, an entry for a person might contain values of attributes of 
type common name, telephone number, e-mail address and job title. All X.500 entries 
have the unambiguous naming structure called the Directory Information Tree (DIT) as 
shown in Figure 6.12. The DIT has a single conceptual root and unlimited further vertices 
with distinguished names. The DN for an entry is constructed by joining the DN of its 
immediate superior entry in the tree with a relative distinguished name (RDN). 

Suppose a staff member of the organisation has an X.500 name. If this person leaves 
the corporation and a new staff member joins the corporation and is reassigned the same 
X.500 name, this may cause authorisation ambiguities in the access control of X.500 data 
objects. The idea of the unique identifier fields in the X.509 v2 certificate format is that 
a new value could be put in this field whenever an X.500 name is reused. Unfortunately, 
unique identifiers do not contribute a very reliable solution to this problem due to the 
managing difficulty. A much better approach is to systematically ensure that all X.500 
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Figure 6.12 The DIT example of X.500 naming. 
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names are unambiguous. This can be achieved by an RDN and a new attribute value, 
ensuring that employee numbers are not reused over time. 


6.4.5 Secure Key Generation and Distribution 


Each user must assure the integrity of the received key and must rely on the PKI to supply 
the public keys generated from associated certificates. 

Consider a scenario in which a user’s public/private-key pair can be generated, certified 
and distributed. There are two ways to consider: 


e The user generates his or her own public/private-key pair. In this way, the user is 
responsible for ensuring that he or she used a good method for generating the key 
pair. The user is also responsible for having his or her public key certified by a CA. 
The advantage for the user of generating the key pair is that the user’s private key is 
never released to another entity. This allows for the provision of true non-repudiation 
services. The user must store his or her private key in a tamperproof secure location 
such as on a smart card, floppy disk or PCMCIA card. 

e A trusted third party generates the key pair for the user. This method assumes that 
security measures are employed by the third party to prevent tampering. To obtain a 
key pair from another entity such as a centralised Key Generator (KG), the user goes 
to the KG and requests the KG to generate a key pair. This KG will be collocated 
with either a CA or an ORA. The KG generates the key pair and gives the public and 
private keys to the user. The private key must certainly be transmitted to the user in 
a secure manner such as on a token which might be a smart card, a PCMCIA card or 
an encrypted diskette. It is not appropriate for the KG to send the user’s public key 
to the CA for certification. It must give the copy of the public key to the user so that 
he or she can be properly identified during the certificate generating procedure. The 
KG also automatically destroys the copy of the user’s private key once it has been to 
the user. 


If key generation is conducted by a trusted third party on behalf of the user, it is 
necessary to assure the integrity of the public key and the confidentiality of the private key. 
Therefore, the generation and distribution of key pairs must be done in a secure fashion. 

CA keys are generated by the CA itself. Thus, the PAA, the PCAs and CAs all generate 
their own key pairs. An ORA can generate its own key pair or have it generated by a 
third party depending upon PCA policy. A PCA has its public key certified by the PAA. 
At that time, it can obtain the PAA’s public key. A CA’s public key is certified by the 
appropriate PCA. 

Besides these elements, other important key elements for PKI operations are X.509 
certificates, certificate revocation lists, and certification path validation. These subjects 
are covered in the following three sections, respectively. 


6.5 X.509 Certificate Formats 


These formats are described in this section and an algorithm for X.509 certificate path 
validation is also discussed. The specification profiles the format of certificates and cer- 
tificate revocation lists for the Internet PKIX. Procedures are described for processing 
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certification paths in the Internet environment. Encryption and authentication rules are 
provided with well-known cryptographic algorithms. 

X.500 specifies the directory service. X.509 describes the authentication service using 
the X.500 directory. A standard certificate format of X.509 which was defined by ITU-T 
X.509 (formerly CCITT X.509) or ISO/IEC/ITU 9594-8 was first published in 1988 as 
part of the X.500 directory recommendations. The certificate format in the 1988 standard 
is called the version | (vl) format. When X.500 was revised in 1993, two more fields 
were added, resulting in the version 2 (v2) format. These two fields are used to support 
directory access control. 

The Internet Privacy Enhanced Mail (PEM), published in 1993, includes specifications 
for a PKI based on the X.509 v1 certificate (RFC 1422). Experience has shown that the 
X.509 vl and v2 certificate formats are not adequate enough in several aspects. It was 
found that more fields were needed to contain necessary information for PEM design 
and implementation. In response to these new requirements, ISO/IEC/ITU and ANSI X9 
developed the X.509 v3 certificate format. It extends the v2 format by including additional 
fields. Standardisation of the basic format of X.509 v3 was completed in June 1996. 

The standard extensions for use in the v3 extensions field can convey data such as 
subject identification information, key attribute information, policy information and cer- 
tification path constraints. In order to develop interoperable implementations of X.509 
v3 systems for Internet use, it is necessary to specify a profile for use of the X.509 v3 
extensions for the Internet. 

X.509 defines a framework for the provision of authentication services by the X.500 
directory to its users. X.509 is an important standard because the certificate structure and 
authentication protocols defined in X.509 are used in a various areas. The X.509 certificate 
format is used in S/MIME for e-mail security, IPsec for network-level security, SSL/TLS 
for transport-level security, and SET for secure payment systems. 


6.5.1 X.509 v1 Certificate Format 


As stated above, the X.509 certificate format has evolved through three versions: version | 
in 1988, version 2 in 1993 and version 3 in 1996. We start by describing the v1 format. 

This format contains information associated with the subject of the certificate and 
the CA who issued it. The certificate (value equals 0) contains a version number, a serial 
number, the CA signature algorithm, the names of the subject and issuer, a validity period, 
a public key associated with the subject, and a issuer’s signature. These basic fields are 
as shown in Figure 6.13. The certificate fields are interpreted as follows: 


e Version: In this field the format of the certificate is identified as the indicator of version 
1, 2 or 3 format. The 1988 X.509 certificate v1 format is used only when basic fields 
are present. The value of this field in a v1 format is assigned as ‘0’. The v2 certificate 
format is assigned the value ‘1’. The value of this field is 2, signifying a v3 certificate. 

e Serial number: This is an integer assigned by the CA to each certificate. In other 
words, this field contains a unique identifying number for this certificate, assigned by 
the issuing CA. The issuer must ensure that it never assigns the same serial number 
to two distinct certificates. 
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Certificate fields Interpretation of contents 





Version Version of certificate format 





Serial number Certificate serial number 





Signature algorithm identifier 


Signawire’algorithm for certificate issuer’s signature 





Issuer CA’s X.500 name 





Validity period Start and expiry dates/times 





Subject name Subject X.500 name 





Algorithm identifier and subject public- 
key value 


Subject public-key information 





Issuer’s signature Certificate Authority’s digital signature 

















Figure 6.13 X.509 version | certificate format. 


e Signature: The algorithm used by the issuer in order to sign the certificate is specified. 
The signature field contains the algorithm identifier for the algorithm used to sign the 
certificate. 

e Issuer: This field provides a globally unique identifier of the authority signing the 
certificate. The syntax of the issuer name is an X.500 distinct name. This field contains 
the X.500 name of the issuer that generated and signed the certificate. The DN is 
composed of attribute type—attribute value pairs. 

e Validity: This field denotes the start and expiry dates/times for the certificate. The 
validity field indicates the dates on which the certificate becomes valid (not before) 
and on which the certificate ceases to be valid (not after). In other words, it contains 
two time and date indications that denote the start and the end of the time period for 
which the certificate is valid. The validity field always uses UTCTime (Coordinated 
Universal Time) which is expressed in Greenwich Mean Time (Zulu). 

e Subject: The purpose of the subject field is to provide a unique identifier of the subject 
of the certificate. The syntax of the subject name will be an X.500 DN. This field 
contains the name of the entity for whom the certificate is being generated. The field 
denotes the X.500 name of the holder of the private key, for which the corresponding 
public key is being certified. 

e Subject public-key information: This field contains the value of a public key of the 
subject together with an identifier of the algorithm with which this public key is to 
be used. It includes the subject public-key field and an algorithm identifier field with 
algorithm and parameters subfields. 
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e Issuer’s signature: This field denotes the CA’s signature for which the CA’s private 
key is used. The actual signature on the certificate is defined by the use of a sequence 
of the data being signed, an algorithm identifier and a bit string which is the actual sig- 
nature. The algorithm identifier is used to sign the certificate. Although this algorithm 
identifier field includes a parameter field that can be utilised to pass the parameters 
used by the signature algorithm, it is not itself a signed object. The parameter field 
of the certificate signature is not to be used to pass parameters. When parameters 
are used to validate a signature, they may be obtained from the subject public-key 
information field of the issuing CA’s certificate. 


Experience has shown that the X.509 v1 certificate format is deficient in several respects. 
The v2 format extends the v1 format by including two more identifier fields. 


6.5.2 X.509 v2 Certificate Format 


RFC 1422 uses the X.509 v1 certificate format, which imposes several structural restric- 
tions on clearly associating policy information and restricts the utility of certificates. The 
X.509 v2 format imposed by RFC 1422 can be addressed using two more fields — issuer 
and subject unique identifiers which are illustrated in Figure 6.14. These two added fields 
are interpreted as follows: 


e Issuer unique identifier: This field is present in the certificate to deal with the possi- 
bility of reuse of issuer names over time. In this field, an optional bit string is used 
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Figure 6.14 X.509 version 2 certificate format. 
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to make the issuer’s name unambiguous in the event that the same name has been 
reassigned to different entities over time. 

e Subject unique identifier: This field is present in the certificate to deal with the pos- 
sibility of reuse of subject names over time. This field is an optional bit string used 
to make the subject name unambiguous in the event that the same name has been 
reassigned to different entities over time. 


Submissive CAs do not issue certificates that include these unique identifiers. Submissive 
PKI clients are not required to process certificates that include these unique identifiers. 
However, if they do not process these fields, they are required to reject certificates that 
include these fields. 


6.5.3 X.509 v3 Certificate Format 


The Internet PEM RFCs, published in 1993, include specifications for a PKI based on 
X.509 v1 certificates. The experience gained from RFC 1422 indicates that the v1 and v2 
certificate formats are deficient in several respects. In response to the new requirements 
and to overcome the deficiencies, ISO/IEC/ITU and ANSI X9 developed the X.509 v3 
certificate format. This format extends the v2 format by including provision for additional 
extension fields. The addition of these extension fields is the principal change introduced 
to the v3 certificate. 

Although the revision to ITU-T X.509 that specifies the v3 format is not yet published, 
the v3 format has been widely adopted and is specified in ANSI X 9.55—1995, and the 
IETF’s Internet Public Key Infrastructure working document (PKIX1). In June 1996, 
standardisation of the basic X.509 v3 was completed. The v3 certificate includes the 
11 fields as shown in Figure 6.15. The version field describes the version of the encoded 
certificate. The value of this field is 2, signifying a version 3 certificate. 

ISO/IEC/ITU and ANSI X9 have also developed standard extensions for use in the 
v3 extensions field. These extensions can convey data such as additional subject identi- 
fication information, key attribute information, policy information and certification path 
constraints. In order to develop interoperable implementations of X.509 v3 systems for 
Internet use, it will be necessary to specify a profile for use of the v3 extensions tailored 
for the Internet. 

The extensions defined for the v3 certificates provide methods for associating additional 
attributes with users or public keys and for managing the certification hierarchy. The v3 
format also allows communities to define private extensions to carry information unique 
to those communities. 

Each extension includes an OID and an ASN.1 structure. When an extension appears 
in a certificate, the OID appears as the field extnID and the corresponding ASN.1 encoded 
structure is the value of the octet string extn Value. 

Conforming CAs must support such extensions as authority and subject key identifiers, 
key usage, certification policies, subject alternative name, basic constraint, and name and 
policy constraints. The format and content of certificate extensions in the Internet PKI 
are described in the following. 

The standard extensions can be divided into the following groups: 
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Certificate fields Interpretation of contents 


Version, serial number, signature 
algorithm, issuer, validity period, 
subject name, subject public-key 
information 


vl=v2=v3 
(for seven fields) 





Issuer unique identifier 
subject unique identifier 


v2 = v3 
(for two fields) 





Key and policy information 





Extensions Subject and issuer attributes 
(v3) Certification path constraints 
Extensions related to CRLs 
vl=v2=v3 I fait 
(for the last field) Ssueh s Signature 




















Figure 6.15 X.509 version 3 certificate format. 


Key and policy information 
Subject and issuer attributes 
Certification path constraints 
Extensions related to CRLs. 


6.5.3.1 Key and Policy Information Extensions 


The key and policy information extensions convey additional information about the subject 
and issuer keys. The extensions also convey indicators of certificate policy. The extensions 
facilitate the implementation of PKI and allow administrators to limit the purposes for 
which certificates and certified keys are used. 


Authority key identifier extension 


The authority key identifier extension provides a mean of identifying the public key 
corresponding to the private key used to sign a certificate. This extension is used where 
an issuer has multiple signing keys. The identification is based on either the subject key 
identifier in the issuer’s certificate or the issuer name and serial number. 
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The key identifier field of the authority key identifier extension must be included in 
all certificates generated by conforming CAs to facilitate chain building. The value of the 
key identifier field should be derived from the public key used to verify the certificate’s 
signature or a method that generates unique values. This field helps the correct certificate 
for the next certification authority in the chain to be found. 


Subject key identifier extension 


The subject key identifier extension provides a means of identifying certificates that con- 
tain a particular public key. 

To facilitate chain building, this extension must appear in all conforming CA certifi- 
cates including the basic constraints extension. The value of the subject key identifier 
is the value placed in the key identifier field of the authority key identifier extension of 
certificates issued by the subject of the certificate. 

For CA certificates, subject key identifiers should be derived from the public key or a 
method that generates unique values. Two common methods for generating key identifiers 
from the public key are: 


e The key identifier is composed of the 160-bit SHA-1 hash value of the bit string of 
the subject public key. 

e The key identifier is composed of a four-bit-type field with 0100 followed by the least 
significant 60 bits of the SHA-1 hash value of the bit string of the subject public key. 


For end entity certificates, the subject key identifier extension provides a means of iden- 
tifying certificates containing the particular public key used in an application. For an 
end entity which has obtained multiple certificates from multiple CAs, the subject key 
identifier provides a mean to quickly identify the set of certificates containing a particular 
public key. 


Key usage extension 


This extension defines the key usage for encryption, signature and certificate signing with 
the key contained in the certificate. When a key which is used for more than one operation 
is to be restricted, the usage restriction is required to be employed. An RSA key should be 
used only for signing; the digital signature and/or non-repudiation bits would be asserted. 
Likewise, when an RSA key is used only for key management, the key encryption bit 
would be asserted. Bits in the key usage type are used as follows: 


Key Usage :: = Bit String { 
digital signature bit (0 
non-repudiation bit (1 
key encryption bit (2 
data encryption bit (3 
key certificate sign bit (4 
key agreement sign bit (5 
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CRL sign bit (6) 
encipher only bit (7) 
decipher only bit (8) } 


e The digital signature bit is asserted when the subject public key is used with a digital 
signature mechanism to support security services other than non-repudiation (bit 1), 
certificate signing (bit 5) or revocation information signing (bit 6). Digital signature 
mechanisms are often used for entity authentication and data origin authentication 
with integrity. 

e The non-repudiation bit (bit 1) is asserted when the subject public key is used to 
verify digital signatures used to provide a non-repudiation service. This service pro- 
tects against the signing entity falsely denying some action, excluding certificate or 
CRL signing. 

e The key encryption bit (bit 2) is asserted when the subject public key is used for key 
transport. For example, when an RSA key is used for key management, then this bit 
will be asserted. 

e The data encryption bit (bit 3) is asserted when the subject public key is used to 
encipher user data, other than cryptographic keys. 

e The key agreement bit (bit 4) is asserted when the subject public key is used for key 
agreement. For example, when Diffie-Hellman exchange is used for key management, 
then this bit will be asserted. 

e The key certificate signing bit (bit 5) is asserted when the subject public key is used 
to verify a signature on certificates. This bit is only asserted in CA certificates. 

e The CRL sign bit (bit 6) is asserted when the subject public key is used to verify a 
signature on revocation information. 

e The encipher only bit (bit 7) is undefined in the absence of the key agreement bit. 
When this bit is asserted and the key agreement bit is also set, the subject public key 
can be used only to encipher data while performing key agreement. 

e The decipher only bit (bit 8) is undefined in the absence of the key agreement bit. 
When the decipher only bit is asserted and the key agreement bit is also set, the subject 
public key can be used only to decipher data while performing key agreement. 


This profile does not restrict the combinations of bits that may be set in an instantiation 
of the key usage extension. 


Private-key usage period extension 


This extension allows the certificate issuer to specify a different validity period for the 
private key than the certificate. The extension is intended for use with digital signature 
keys and consists of two optional components, ‘not before’ and ‘not after’. The private 
key associated with the certificate should not be used to sign objects before or after the 
times specified by the two components, respectively. CAs conforming to this profile must 
not generate certificates with private-key usage period extensions unless at least one of 
the two components is present. 
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Certificate policies extension 


This extension contains a sequence of one or more policy information terms, each of which 
consists of an object identifier (OID) and optional qualifiers. These policy information 
terms indicate the policy under which the certificate has been issued and the purposes 
for which it may be used. Optional qualifiers are not expected to change the definition of 
the policy. 

Applications with specific policy requirements are expected to list those policies which 
they will accept and to compare the policy OIDs in the certificate with that list. If the 
certificate policies extension is critical, the path validation software must be able to 
interpret this extension, or must reject the certificate. To promote interoperability, this 
profile recommends that policy information terms consist only of an OID. 


Policy mappings extension 


This extension is used in CA certificates. It lists one or more pairs of OIDs. Each pair 
includes an issuer domain policy and a subject domain policy. The pairing indicates that 
the issuing CA considers its issuer domain policy equivalent to the subject CA’s subject 
domain policy. The issuing CA’s users may accept an issuer domain policy for certain 
applications. The policy mapping tells the issuing CA’s users which policies associated 
with the subject CA are comparable with the policy they accept. This extension may be 
supported by CAs and/or applications, and it must be non-critical. 


6.5.3.2 Subject and Issuer Attributes Extensions 


These extensions support alternative names for certificate subjects and issuers. They can 
also convey additional attribute information about the subject to help a certificate user 
gain confidence that the certificate applies to a particular person, organisation or device. 
These extensions are as follows. 


Subject alternative name extension 


This extension allows additional identities to be bound to the subject of the certificate. 
Defined options include an Internet e-mail or EDI address, a DNS name, an IP address 
and a uniform resource identifier (URI). 

Whenever such identities are bound into a certificate, the subject alternative name (or 
issuer alternative name) extension must be used. 

Since the subject alternative name is considered to be definitively bound to the public 
key, all parts of the subject alternative name must be verified by the CA. 


Issuer alternative name extension 


As with the previous section, this extension field contains one or more alternative names 
for the certificate issuer. The name forms are the same as for the subject alternative name 
extension. This extension is used to associate Internet-style identities with the certificate 
issuer. This field provides for CAs that are accessed via the Web or e-mail. 
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Subject directory attributes extension 


This extension field conveys any desired X.500 attribute values for the subject of the 
certificate. It provides a general means of conveying additional identifying information 
about the subject beyond what is conveyed in the name field. This extension is not 
recommended as an essential part of this profile, but it may be used in local environments. 
The extension must be non-critical. 


6.5.3.3 Certification Path Constraints Extensions 


These extensions help different organisations link their infrastructures together. When one 
CA certifies another CA, it can include, in the certificate, information advising certificate 
users of restrictions on the types of certification paths that can stem from this point. These 
extensions are as follows: 


Basic constraints extension 


This indicates whether the certificate subject acts as a CA or is an end entity only. This 
indicator is important to prevent end-users from fraudulently emulating CAs. If the subject 
acts as a CA, a certification path length constraint may also be specified on how deep 
a certification path may exist through that CA. For example, this extension field may 
indicate that certificate users must not accept certification paths that extend more than 
one certificate from this certificate. 


Name constraints extension 


This extension must be used only in a CA certificate. The extension indicates a name 
space within which all subject names in subsequent certificates in a certification path 
are located. Restrictions apply only when the specified name form, either the subject 
distinguished name or subject alternative name, is present. In other words, if no name of 
this type is in the certificate, the certificate is acceptable. Restrictions are defined in terms 
of permitted or excluded name subtrees. Any name matching a restriction in the excluded 
subtrees field is invalid regardless of the information appearing in the permitted subtrees. 

For URIs, the constraint applies to a host or a domain. Examples would be ‘foo.bar.com’ 
and ‘.xyz.com’. When the constraint begins with a full stop, the constraint ‘.xyz.com’ can 
be expanded with one or more subdomains such as ‘abc.xyz.com’ and ‘abc.def.xyz.com’. 
When the constraint does not begin with a full stop, it specifies a host. 

For a name constraint for Internet mail addresses, it specifies a particular mailbox, 
all addresses at a particular host, or all mailboxes in a domain. To indicate a particular 
mailbox, the constraint is the complete address. For example, ‘root@xyz.com’ indicates 
the root mailbox on the host ‘xyz.com’. To indicate all Internet mail addresses on a 
particular host, the constraint is specified as the host name. 

DNS name restrictions are expressed as “foo.bar.com’. Any DNS name constructed by 
simply adding to the left hand side of the name satisfies the name constraint. For example, 
‘www.foo.bar.com’ would satisfy the constraint. 
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Policy constraints extension 


The policy constraints extension is used in certificates issued to CAs. This extension 
constrains path validation in two ways: 


e Inhibited policy-mapping field: This field can be used to prohibit policy mapping. 
If the inhibited policy-mapping field is present, the value indicates the number of 
additional certificates that may appear in the path before policy mapping is no longer 
permitted. For example, a value of one indicates that policy mapping is processed in 
certificates issued by the subject of this certificate, but not in additional certificates in 
the path. 


e Required explicit policy field: This field can be used to require that each certificate in 
a path contain an acceptable policy identifier. If the required explicit policy field is 
present, subsequent certificates will include an acceptable policy identifier. The value 
of this explicit field indicates the number of additional certificates that may appear in 
the path before an explicit policy is required. An acceptable policy identifier is the 
identifier of a policy required by the user of the certification path or one which has 
been declared equivalent through policy mapping. 


Conforming CAs must not issue certificates where policy constraints form a null sequence. 
At least one of the inhibited policy-mapping field or the required explicit policy field must 
be present. 


Extended key usage field 


This field indicates one or more purposes for which the certified public key can be used 
in place of the basic purposes in the key usage extension field. Key purposes can be 
defined by any organisation. Object identifiers used to identify key purposes are assigned 
in accordance with IANA or ISO/IEC/ITU 9834-1. 

This extension at the option of the certificate issuer is either critical or non-critical. 
If the extension is flagged as critical, then the certificate must be used only for one of 
the purposes indicated. If the extension is flagged as non-critical, then it indicates the 
intended purpose or purposes of the key and can be used to find the correct key/certificate 
of an entity that has multiple keys/certificates. It is an advisory field and does not imply 
that usage of the key is restricted by the CA to the purpose indicated. 

If a certificate contains both a critical key usage field and a critical extended key usage 
field, then both fields must be processed independently and the certificate must only be 
used for a purpose consistent with both fields. If there is no purpose consistent with both 
fields, then the certificate must not be used for any purpose. 


CRL distribution points extension 


The CRL distribution points extension identifies how CRL information is obtained. The 
extension should be non-critical, but CAs and applications must support it. If this extension 
contains a distribution point name of type URL, the URI is a pointer to the CRL. When 
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the subject alternative name extension contains a URI, the name must be stored in the 
URI (an IAS5String). 


6.5.3.4 Private Internet Extensions 


This section defines one new extension for use in the Internet PKI. This extension may be 
used to direct applications to identify an online validation service supporting the issuing 
CA. As the information may be available in multiple forms, each extension is a sequence 
of [A5String values, each of which represents a URI. The URI implicitly specifies the 
location and format of the information. It also specifies the method for obtaining the 
information. 

An object identifier is defined for the private extension. The object identifier associated 
with the private extension is defined under the arc id-pe within the id-pkix name space. 
Any future extensions defined for the Internet PKI will also be defined under the arc id-pe. 


Authority information access extension 


This extension indicates how to access CA information and services for the issuer of the 
certificate in which the extension appears. Information and services may include online 
validation services and CA policy data. 

Each entry in this information access syntax describes the format and location of 
additional information about the CA who issued the certificate. The information type and 
format are specified by the access method field, while the access location field specifies 
the location of the information. The retrieval mechanism may be implied by the access 
method or specified by the access location. 

This profile defines one OID for the access method. The id-ad-calssuers OID is used 
when the additional information lists CAs that have issued certificates superior to the CA 
that issued the certificate containing this extension. The referenced CA issuers description 
is intended to help certificate users select a certification path that terminates at a point 
trusted by the certificate user. 

When id-ad-calssuers appears as the access information type, the access location field 
describes the referenced description server and the access protocol to obtain the refer- 
enced description. The access location field is defined as a general name, which can take 
several forms. 

Where the information is available via http, ftp or ldap, the access location must be 
a URI. Where the information is available via the Directory Access Protocol (dap), the 
access location must be a directory name. When the information is available via e-mail, 
the access location must be an RFC 2822 name. 


6.6 Certificate Revocation List 


CRLs are used to list unexpired certificates that have been revoked. Certificates may 
be revoked for a variety of reasons, ranging from routine administrative revocations to 
situations where the private key is compromised. 
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CRLs are used in a wide range of applications and environments covering a broad spec- 
trum of interoperability goals and an even broader spectrum of operational and assurance 
requirements. 

The ISOMIEC/AITU X.509 standard also defines the X.509 CRL format that, like the 
certificate format, has evolved somewhat since first appearing in 1998. In fact, when the 
extensions field was added to the certificate to create the X.509 v3 certificate format, the 
same type of mechanism was added to the CRL to create the X.509 v2 CRL format. 
The main elements of the X.509 v2 CRL are shown in Figure 6.16. The X.509 v2 CRL 
format is augmented by several optional extensions, similar in concept to those defined 
for certificates. CAs are able to generate X.509 v2 CRLs. 


6.6.1 CRL Fields 
The following items describe the use of the X.509 v2 CRL: 


e Version: This optional field describes the version of the encoded CRLs. The integer 
value of this field is 1, indicating a v2 CRL. When extensions are used, this field must 
be present and must specify the v2 CRL. 





X.509 CRL format 


Yes ionopuonal) This field is present only if extensions are used 





For CRL issuer’s signature, signature algorithm 








Signature (RSA or DSA) and hash function (MD5 or SHA-1) 
Issuer name CRL issuer (X.500 distinguished name) 
This update Issue the data of CRL (date/time) 





Issue the CRLs with a next update time equal to 


Next update or later than all previous CRLs (date/Time) 





A list of certificates that have been revoked: 
Identify uniquely by certificate serial 
number 
© Date on the revocation occurrence is 
specified 
Revoked certificates © Optional CRL entry extensions: 
- Give the reason for revoked 
certificate 
- State the data for invalidity 
- State the name of CA issuing 
the revoked certificate 





Authority key identifier 

Issuer alternative name 

CRL number, delta CRL indicator, issuing 
distribution point 


CRL extensions 





Reason code 


CRL entry extensions Hold instruction code 
Invalidity date Certificate issuer 











CRL issuer’s digital signature 





Figure 6.16 X.509 v2 CRL format. 
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e Signature: This field contains the algorithm identifier for the algorithm used to sign 
the CRL. The signature algorithm and one-way hash function used to sign a certificate 
or CRL is indicated by use of an algorithm identifier. The algorithm identifier is an 
OID, and possibly includes associated parameters. RSA and DSA are the most popular 
signature algorithms used in the Internet PKI. The one-way hash functions commonly 
used are MD5 and SHA-1. 


e Issuer name: This identifies the entity which has signed and issued the CRL. The issuer 
identity is carried in the issuer name field. Alternative name forms may also appear 
in the issuer alternative name extension. The issuer name is an X.500 distinguished 
name. The issuer name field is defined as the X.501 type name and must follow the 
encoding rules for the issuer name field in the certificate. 


e This update: This field indicates the issue date of the CRL. The update field may be 
encoded as UTCTime or GeneralisedTime. CAs conforming to this field that issue 
CRLs must encode this update as UTCTime for dates to the year 2049 and as Gener- 
alisedTime for dates to the year 2050 or later. For this specification, where encoded 
as UTCTime, the update field must be specified and interpreted as defined in the rules 
for the certificate validity field. 


e Next update: This field indicates the date by which the next CRL will be issued. It 
could be issued before the indicated date, but it will not be issued any later than that 
date. CAs should issue CRLs with a next update time equal to or later than all previous 
CRLs. The next update field may be encoded as UTCTime or GeneralisedTime. 

This profile requires inclusion of the next update field in all CRLs issued by con- 
forming CAs. Note that the ASN.1 syntax of TBCCertList described this field as 
optional, which is consistent with the ASN.1 structure defined in X.509. CAs con- 
forming to this profile that issue CRLs must encode the next update as UTCTime for 
dates to the year 2049 and as GeneralisedTime for dates to the year 2050 or later. 
For this specification, the next update field should follow the rules for the certificate 
validity field. 

e Revoked certificates: This field is a list of the certificates that have been revoked. 
Each revoked certificate listed contains the following: 


— The revoked certificates are identified by their serial numbers. Certificates revoked 
by the CA are uniquely identified by the certificate serial number. 

— The date on which the revocation occurred is specified. The time for revocation 
must be encoded as UTCTime or GeneralisedTime. 

— The optional CRL entry extensions may give the reason why the certificate was 
revoked, state the date when the invalidity is believed to have occurred, and 
may state the name of the CA that issued the revoked certificate, which may be a 
different CA from the one issuing the CRL. Note that the CA that issued the CRL 
is assumed to be the one that issued the revoked certificate unless the certificate 
issuer CRL entry extension is included. 


6.6.2 CRL Extensions 


The extensions defined by ANSI X9 and ISO/IEC/ITU for X.509 v2 CRLs provide meth- 
ods for associating additional attributes with CRLs. The X.509 v2 CRL format also allows 
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communities to define private extensions to carry information unique to those communi- 
ties. Each extension in a CRL is designated as critical or non-critical. A CRL validation 
must fail if it encounters a critical extension which it does not know how to process. 
However, an unrecognised non-critical extension may be ignored. The extensions used 
within Internet CRLs will be presented in the following: 


Authority key identifier: This extension provides a mean of identifying the public key 
corresponding to the private key used to sign a CRL. The identification can be based 
on either the key identifier or the issuer name and serial number. This extension 
is particularly useful where an issuer has more than one signing key, either due to 
multiple concurrent key pairs or due to changeover. 


Issuer alternative name: This extension is a non-critical CRL extension that allows 
additional identities to be associated with the issuer of the CRL. Defined options 
include an e-mail address, a DNS name, an IP address and a URI. Multiple instances 
of a name and multiple name forms may be included. Whenever such identities are 
used, the issuer alternative name extension must also be used. CAs are capable of 
generating this extension in CRLs, but clients are not required to process it. 


CRL number: This field is a non-critical CRL extension which conveys a monotoni- 
cally increasing sequence number for each CRL issued by a CA. This extension allows 
users to easily determine when a particular delete CRL is replaced by another CRL. 
CAs conforming to this profile must include this extension in all CRLs. 


Delta CRL indicator: This is a critical CRL extension that identifies a delta CRL. The 
use of delta CRLs can significantly improve processing time for applications which 
store revocation information in a format other than the CRL structure. This allows 
changes to be added to the local database while ignoring unchanged information that 
is already in the local database. When a delta CRL is issued, the CAs must also issue 
a complete CRL. 


The value of the base CRL number identifies the CRL number of the base CRL that 
was used as the starting point in the generation of this delta CRL. The delta CRL 
contains the changes between the base CRL and the current CRL issued along with 
the delta CRL. It is the decision of a CA as to whether to provide delta CRLs. Again, 
a delta CRL must not be issued without a corresponding complete CRL. The value of 
the CRL number for both the delta CRL and the corresponding complete CRL must 
be identical. 

A CRL user constructing a locally held CRL from delta CRLs must consider the 
constructed CRL as incomplete and unusable if the CRL number of the received delta 
CRL is more than one greater than the CRL number of the delta CRL last processed. 


Issuing distribution point: The issuing distribution point is a critical CRL extension 
that identifies the CRL distribution point for a particular CRL, and it indicates whether 
the CRL covers revocation for end-entity certificates only, CA certificates only, or a 
limited set of reason codes that have been revoked for a particular reason. Although 
the extension is critical, conforming implementations are not required to support this 
extension. The CRL is signed using the CA’s private key. CRL distribution points do 
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not have their own key pairs. If the CRL is stored in the X.500 directory, it is stored 
in the directory entry corresponding to the CRL distribution point, which could be 
different from the directory entry of the CA. 


The reason codes associated with a distribution point are specified in onlySomeRea- 
sons. A ReasonsFlag bit string indicates the reasons for which certificates are listed in 
the CRL. If onlySomeReasons does not appear, the distribution point contains revo- 
cations for all reason codes. CAs may use the CRL distribution point to partition the 
CRL on the bases of compromise and routine revocation. The revocations with reason 
code keyCompromise (used to indicate compromise or suspected compromise) and 
cACompromise (used to indicate that the certificate has been revoked because of a 
CA key compromise) appear in one distribution point, and the revocations with other 
reason codes appear in another distribution point. 


6.6.3  CRL Entry Extensions 


The CRL entry extensions already defined by ANSI X9 and ISO/IEC/ITU for X.509 v2 
CRLs provide methods for associating additional attributes with CRL entries. The X.509 
v2 CRL format also allows communities to define private CRL entry extensions to carry 
information unique to those communities. Each extension in a CRL entry is designated 
as critical or non-critical. A CRL validation must fail if it encounters a critical CRL entry 
extension which it does not know how to process. However, an unrecognised non-critical 
CRL entry extension may be ignored. The following list presents recommended extensions 
used within Internet CRL entries and standard locations for information. 

All CRL entry extensions used in this specification are non-critical. Support for these 
extensions is optional for conforming CAs and applications. However, CAs that issue CRLs 
must include reason codes and invalidity dates whenever this information is available. 


e Reason code: This is a non-critical CRL entry extension that identifies the reason for 
revocation of the certificate. CAs are strongly encouraged to include meaningful reason 
codes in CRL entries. However, the reason code CRL entry extension must be absent 
instead of using the unspecified reason code value (0). The following enumerated 
reasonCode values are defined: 


— unspecified (0) should not be used. 

— all keyCompromise (1) indicates compromise or suspected compromise. 

— cACompromise (2) indicates that the certificate has been revoked because of a 
CA key compromise. It is only used to revoke CA certificates. 

—  affiliationChanged (3) indicates that the certificate was revoked because of a 
change of affiliation of the certificate subject. 

— superseded (4) indicates that the certificate has been replaced by a more recent 
certificate. 

—  cessationOfOperation (5) indicates that the certificate is no longer needed for the 
purpose for which it was issued, but there is no reason to suspect that the private 
key has been compromised. 
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— certificateHold (6) indicates that the certificate will not be used at this time. 
When clients process a certificate that is listed in a CRL with a reasonCode 
of certificateHold, they will fail to validate the certification path. 

— removeFromCRL (7) is used only with delta CRLs and indicates that an existing 
CRL entry should be removed. 


e Hold instruction code: This code is a non-critical CRL entry extension that provides 
a registered instruction identifier. This identifier indicates the action to be taken after 
encountering a certificate that has been placed on hold. 


e Invalidity date: This is a non-critical CRL entry extension that provides the date on 
which it is known or suspected that the private key was compromised or that the 
certificate otherwise became invalid. The invalidity date is the date at which the CA 
processed the revocation, but it may be earlier than the revocation date in the CRL 
entry. When a revocation is first posted by a CA in a CRL, the invalidity date may 
precede the date of issue of earlier CRLs. However, the revocation date should not 
precede the date of issue of earlier CRLs. Whenever this information is available, 
CAs are strongly encouraged to share it with CRL users. The generalised time values 
included in this field must be expressed in Greenwich Mean Time (Zulu). 


e Certificate issuer: This CRL entry extension identifies the certificate issuer associated 
with an entry in an indirect CRL (i.e. a CRL that has the indirect CRL indicator 
set in its issuing distribution point extension). If this extension is not present on the 
first entry of an indirect CRL, the certificate issuer defaults to the CRL issuer. On 
subsequent entries of an indirect CRL, if this extension is not present the certificate 
issuer for the entry is the same as the issuer of the preceding CRL entry. 


6.7 Certification Path Validation 


The certification path validation procedure for the Internet PKI describes the verification 
process for the binding between the subject distinguished name and/or subject alternative 
name and subject public key. The binding is limited by constraints that are specified in 
the certificates which comprise the path. 

This section describes an algorithm for validating certification paths. For basic path 
validation, all valid paths begin with certificates issued by a single most-trusted CA. The 
algorithm requires the public key of the CA, the CA’s name, the validity period of the 
public key, and any constraints upon the set of paths which may be validated using this 
key. Depending on policy, the most-trusted CA could be a root CA in a hierarchical PKI, 
the CA that issued the verifier’s own certificate, or any other CA in a network PKI. The 
path validation procedure is the same regardless of the choice of the most-trusted CA. 

This section also describes extensions to the basic path validation algorithm. Two 
specific cases are considered: (1) the case where paths are begun with one of several 
trusted CAs; and (2) where compatibility with the PEM architecture is required. 
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6.7.1. Basic Path Validation 


It is assumed that the trusted public-key and related information is contained in a self- 
signed certificate in order to simplify the description of the path processing procedure. 
Note that the signature on the self-signed certificate does not provide any security services. 

The goal of path validation is to verify the binding between a subject distinguished 
name or subject alternative name and subject key, as represented in the end-entity certifi- 
cate, based on the public key of the most-trusted CA. This requires obtaining a sequence 
of certificates which support that binding. 

A certification path is a sequence of n certificates where, for all x in {1, (n — 1)}, the 
subject of certificate x is the issuer of certificate x + 1. Certificate x = 1 is the self-signed 
certificate, and certificate x = n is the end-entity certificate. 

The inputs that are provided to the path processing logic are assumed as follows: 


e A certificate path of length n. 

e A set of initial policy identifiers which identifies one or more certificate policies. 
e The current date and time. 

e The time T for which the validity of the path must be determined. 


From the inputs, the procedure initialises five state variables: 


e Acceptable policy set: A set of certificate policy identifiers comprising the policy or 
policies recognised by the public-key user together with policies considered equivalent 
through policy mapping. 

e Constrained subtrees: A set of root names defining a set of subtrees within which all 
subject names in subsequent certificates in the certification path will fall. 

e Excluded subtrees: A set of root names defining a set of subtrees within which no 
subject name in subsequent certificates in the certification path may fall. 

e Explicit policy: An integer that indicates if an explicit policy identifier is required. The 
integer indicates the first certificate in the path where this requirement is imposed. 

e Policy mapping: An integer which indicates if policy mapping is permitted. The integer 
indicates the last certificate on which policy mapping can be applied. 


The actions performed by the path processing software for each certificate x = 1 to n 
are described below. The self-signed certificate is x = 1 and the end-entity certificate 
isx =n. 


e Verify the basic certificate information: 


— The certificate was signed using the subject public key from certificate x — 1. For 
the special case x = 1, this step is omitted. 

— The certificate validity period includes time T. 

— The certificate had not been revoked at time T and is not currently on hold, a 
status that commenced before time T. 

— The subject and issuer names chain correctly; that is, the issuer of this certificate 
was the subject of the previous certificate. 


e Verify that the subject name and subject alternative name extension are consistent 
with the constrained subtree state variables. 
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e Verify that the subject name and subject alternative name extension are consistent 
with the excluded subtree state variables. 
e Verify that policy information is consistent with the initial policy set: 


— If the explicit policy state variable is less than or equal to x, a policy identifier 
in the certificate should be in the initial policy set. 

— If the policy-mapping variable is less than or equal to x, the policy identifier may 
not be mapped. 


e Verify that policy information is consistent with the acceptable policy set: 


— If the certificate policies extension is marked as critical, the intersection of the 
policies extension and the acceptable policy set will be non-null. 
— The acceptable policy set is assigned the resulting intersection as its new value. 


e Verify that the intersection of the acceptable policy set and the initial policy set is 

non-null. 

Recognise and process any other critical extension present in the certificate. 

Verify that the certificate is a CA certificate as specified in a basic constraints extension 
or as verified out of band. 

e If permittedSubtrees is present in the certificate, set the constrained subtree state 
variable to the intersection of its previous value and the value indicated in the exten- 
sion field. 

e If excludedSubtrees is present in the certificate, set the excluded subtree state variable 
to the union of its previous value and the value indicated in the extension field. 

e If a policy constraints extension is included in the certificate, modify the explicit 
policy and policy-mapping state variable as follows: 


— If the required explicit policy is present and has value r, the explicit policy state 
variable is set to the minimum of its current value and the sum of r and x. 

— If the inhibited policy mapping, whose value is q, is present, the policy-mapping 
state variable is set to the minimum of its current value and the sum of q and x. 


e Ifa key usage extension is marked as critical, ensure the KeyCertSign bit is set. 


If any one of the above checks fails, the procedure terminates, returning a failure indication 
and an appropriate reason; if none of the above checks fail on the end-entity certificate, 
the procedure terminates, returning a success indication together with the set of all policy 
qualifier values encountered in the set of certificates. 


6.7.2 Extending Path Validation 


The path validation algorithm presented in Section 6.7.1 is based on a simplifying assump- 
tion, i.e. a single trusted CA that starts all valid paths. This algorithm can be extended 
for multiple trusted CAs by providing a set of self-signed certificates to the validation 
module. In this case, a valid path could begin with any one of the self-signed certifi- 
cates. Limitations in the trust paths for any particular key may be incorporated into the 
self-signed certificate’s extensions. In this way, the self-signed certificates permit the path 
validation module to automatically incorporate local security policy and requirements. 
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It is also possible to specify an extended version of the above certification path pro- 
cessing procedure which results in a default behaviour identical to the rules of PEM of 
REC 1422. In this extended version, additional inputs to the procedure are a list of one 
or more PCA names and an indicator of the position in the certification path where the 
PCA is expected. At the nominated PCA position, if the CA name is found, then a con- 
straint of SubordinateToCA is implicitly assumed for the remainder of the certification 
path and processing continues. If no valid PCA name is found, and if the certification 
path cannot be validated on the basis of identified policies, then the certification path is 
considered invalid. 

The PKI scheme discussed in this chapter is chiefly embodied in the US scheme 
of public-key infrastructure. After the appearance of the US version, several countries 
devised their own PKI systems, mostly derived from many of the principles and system 
architectures originating from the US PKI scheme. These systems are: 


USA: Federal Public Key Infrastructure (FPKT) 
Europe: European Trusted Service (ETS) and Internetworking Public Key 
Certification of Europe (ICE-TEL) 
Australia: Public Key Authentication Framework (PKAF) 
Canada: Government of Canada Public Key Infrastructure (GoC-PKI) 
Korea: GPKI for government sector and NPKI for Civilian sector 


It will be worthwhile for readers to examine each country’s PKI system through its 
Website. 


7 


Network Layer Security 


TCP/IP communication can be made secure with the help of cryptography. Cryptographic 
methods and protocols have been designed for different purposes in securing communica- 
tion on the Internet. These include, for instance, the SSL and TLS for HTTP Web traffic, 
S/MIME and PGP for e-mail and IPsec for network layer security. This chapter mainly 
addresses security only at the IP layer and describes various security services for traffic 
offered by IPsec. 


7.1. IPsec Protocol 


IPsec is designed to protect communication in a secure manner by using TCP/IP. The 
IPsec protocol is a set of security extensions developed by the IETF and it provides 
privacy and authentication services at the IP layer by using modern cryptography. 

To protect the contents of an IP datagram, the data is transformed using encryption 
algorithms. There are two main transformation types that form the basics of IPsec, the 
Authentication Header (AH) and the Encapsulating Security Payload (ESP). Both AH and 
ESP are two protocols that provide connectionless integrity, data origin authentication, 
confidentiality and an anti-replay service. These protocols may be applied alone or in 
combination to provide a desired set of security services for the IP layer. They are 
configured in a data structure called a Security Association (SA). 

The basic components of the IPsec security architecture are explained in terms of the 
following functionalities: 


e Security Protocols for AH and ESP 

e Security Associations for policy management and traffic processing 

e Manual and automatic key management for the Internet Key Exchange (IKE), the 
Oakley key determination protocol and ISAKMP. 

e Algorithms for authentication and encryption 
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The set of security services provided at the IP layer includes access control, connection- 
less integrity, data origin authentication, protection against replays and confidentiality. The 
modularity which is designed to be algorithm independent permits selection of different 
sets of algorithms without affecting the other parts of the implementation. 

A standard set of default algorithms is specified to facilitate interoperability in the 
global Internet. The use of these algorithms in conjunction with IPsec traffic protection 
and key management protocols is intended to permit system and application developers 
to deploy high-quality, Internet layer, cryptographic security technology. Thus, the suite 
of IPsec protocols and associated default algorithms is designed to provide high-quality 
security for Internet traffic. 

An IPsec implementation operates in a host or a security gateway environment, afford- 
ing protection to IP traffic. The protection offered is based on requirements defined 
by a Security Policy Database (SPD) established and maintained by a user or system 
administrator. 

IPsec provides security services at the IP layer by enabling a system to select the 
required security protocols, determine the algorithms to use for the services, and put in 
place any cryptographic keys required to provide the requested service. IPsec can be used 
to protect one or more paths between a pair of hosts, between a pair of security gateways 
(routers or firewalls) or between a security gateway and a host. 


7.1.1. IPsec Protocol Documents 


This section will discuss the protocols and standards which apply to IPsec. The set of 
IPsec protocols is divided into seven groups as illustrated in Figure 7.1. 

In November 1998, the Network Working Group of the IETF published RFC 2411 
for IP Security Document Roadmap. This document is intended to provide guidelines 
for the development of collateral specifications describing the use of new encryption and 
authentication algorithms used with the AH protocol as well as the ESP protocol. Both 
these protocols are part of the IPsec architecture. The seven-group documents describing 
the set of IPsec protocols are explained in the following: 


e Architecture: The main architecture document covers the general concepts, security 
requirements, definitions and mechanisms defining IPsec technology. 

e ESP: This document covers the packet format and general issues related to the use 
of the ESP for packet encryption and optional authentication. This protocol document 
also contains default values if appropriate, and dictates some of the values in the 
Domain of Interpretation (DOJ). 

e AH: This document covers the packet format and general issue related to the use of 
AH for packet authentication. This document also contains default values such as the 
default padding contents, and dictates some of the values in the DOI document. 

e Encryption algorithm: This is a set of documents that describe how various encryption 
algorithms are used for ESP. Specifically: 


— Specification of the key sizes and strengths for each algorithm. 
— Any available estimates on performance of each algorithm. 
— General information on how this encryption algorithm is to be used in ESP. 
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Figure 7.1 Document overview that defines IPsec. 
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Features of this encryption algorithm to be used by ESP, including encryption 


and/or authentication. 


When these encryption algorithms are used for ESP, the DOI document has to indicate 
certain values, such as an encryption algorithm identifier, so these documents provide 


input to the DOI. 


Authentication algorithm: This is a set of documents that describe how various authen- 
tication algorithms are used for AH and for the authentication option of ESP. 


Specifically: 


— Specification of operating parameters such as number of rounds, and input or 


output block format. 


— Implicit and explicit padding requirements of this algorithm. 
— Identification of optional parameters/methods of operation. 


— Defaults and mandatory ranges of the algorithm. 


— Authentication data comparison criteria for the algorithm. 
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e Key management: This is a set of documents that describe key management schemes. 
These documents also provide certain values for the DOI. Currently the key manage- 
ment represents the Oakley, ISAKMP and Resolution protocols. 

e DOI: This document contains values needed for the other documents to relate each 
other. These include identifiers for approved encryption and authentication algorithms, 
as well as operational parameters such as key lifetime. 


7.1.2 Security Associations (SAs) 


An SA is fundamental to IPsec. Both AH and ESP make use of SAs. Thus, the SA is 
a key concept that appears in both the authentication and confidentiality mechanisms for 
IPsec. An SA is a simplex connection between a sender and receiver that affords security 
services to the traffic carried on it. If both AH and ESP protection are applied to a traffic 
stream, then two SAs are required for two-way secure exchange. 

An SA is uniquely identified by three parameters as follows: 


e Security Parameters Index (SPI): This is assigned to each SA, and each SA is identified 
through an SPI. A receiver uses the SPI to identify the security association for a packet. 
Before a sender uses IPsec to communicate with a receiver, the sender must know 
the index value for a particular SA. The sender then places the value in the SPI field 
of each outgoing datagram. The SPI is carried in AH and ESP headers to enable the 
receiver to select the SA under which a received packet is processed. However, index 
values are not globally specified. A combination of destination address and SPI is 
needed to identify an SA. 

e JP Destination Address: Because, at present, unicast addresses are only allowed by 
IPsec SA management mechanisms, this is the address of the destination endpoint of 
the SA. The destination endpoint may be an end-user system or a network system 
such as a firewall or router. 

e Security Protocol Identifier: This identifier indicates whether the association is an AH 
or ESP security association. 


There are two nominal databases in a general model for processing IP traffic relative to 
SAs, namely, the Security Policy Database (SPD) and the Security Association Database 
(SAD). To ensure interoperability and to provide a minimum management capability 
that is essential for productive use of IPsec, some external aspects for the processing 
standardisation are required. 

The SPD specifies the policies that determine the disposition of all IP traffic inbound 
or outbound from a host or security gateways, while the SAD contains parameters that 
are associated with each security association. 


Security policy database 


The SPD, which is an essential element of SA processing, specifies what services are 
to be offered to IP datagrams and in what fashion. The SPD is used to control the 
flow of all traffic (inbound and outbound) through an IPsec system, including security 
and key management traffic (i.e. ISAKMP). The SPD contains an ordered list of policy 
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entries. Each policy entry is keyed by one or more selectors that define the set of all IP 
traffic encompassed by this entry. Each entry encompasses every indication mechanism 
for bypassing, discarding or IPsec processing. The entry for IPsec processing includes 
SA (or SA bundle) specification, limiting the IPsec protocols, modes and algorithms to 
be employed. 


Security association database 


The SAD contains parameters that are associated with each security association. Each SA 
has an entry in the SAD. For outbound processing, entries are pointed to by entries in 
the SPD. For inbound processing, each entry in the SAD is indexed by a destination IP 
address, IPsec protocol type and SPI. 


Transport mode SA 


There are two types of SAs to be defined: a transport mode SA and a tunnel mode 
SA. A transport mode provides protection primarily for upper-layer protocols, i.e. a TCP 
packet or UDP segment or an Internet Control Message Protocol (ICMP) packet, operating 
directly above the IP layer. A transport mode SA is a security association between two 
hosts. When a host runs AH or ESP over IPv4, the payload is the data that normally 
follows the IP header. For IPv6, the payload is the data that normally follows both the 
IP header and any IPv6 extension headers. In the case of AH, AH in transport mode 
authenticates the IP payload and the protection is also extended to selected portions of 
the IP header, selected portions of IPv6 extension headers and the selected options. 

In the case of ESP, ESP in transport mode primary encrypts and optionally authenticates 
the IP payload but not the IP header. A transport mode SA provides security services only 
for higher-layer protocols, not for the IP header or any extension headers proceeding the 
ESP header. 


Tunnel mode SA 


Tunnel mode provides protection to the entire IP packet. A tunnel mode SA is essentially 
an SA applied to an IP tunnel. Whenever either end of an SA is a security gateway, the 
SA must be tunnel mode, as is an SA between a host and a security gateway. Note that 
a host must support both transport and tunnel modes, but a security gateway is required 
to support only tunnel mode. If a security gateway supports transport mode, it should be 
used as an acting host. But in this case, the security gateway is not as acting a gateway. 

When the entire inner (original) packet travels through a tunnel from one point of the 
IP network to another, routers along the path are unable to examine the inner IP header 
because the original inner packet is encapsulated. As a result, the new larger packet will 
have totally different source and destination addresses. When the AH and ESP fields are 
added to the IP packet, the entire packet plus security field (AH or ESP) is treated as the 
new outer IP packet with a new outer IP header. 

ESP in tunnel mode encrypts and optionally authenticates the entire inner IP packet, 
including the inner IP header. AH in tunnel mode authenticates the entire inner IP packet 
and selected portions of the outer IP header. 
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7.1.3. Hashed Message Authentication Code (HMAC) 


A mechanism that provides a data integrity check based on a secret key is usually called 
the Message Authentication Code (MAC). An HMAC mechanism can be used with any 
iterative hash functions in combination with a secret key. MACs are used between two 
parties (e.g. client and server) that share a secret key in order to validate information 
transmitted between them. An MAC mechanism based on a cryptographic hash function 
is called HMAC. MDS and SHA-1 are examples of such hash functions. HMAC uses 
a secret key for computation and verification of the message authentication values. The 
MAC mechanism should allow for easy replacement of the embedded hash function in 
case faster or more secure hash functions are found or required. That is, if it is desired to 
replace a given hash function in an HMAC implementation, all that is required is simply 
to remove the existing hash function module and replace it with the new, more secure 
module. HMAC can be proven as secure provided that the underlying hash function has 
some reasonable cryptographic strengths. 

Current candidates for secure hash functions include SHA-1, MD5 and RIPEMD-160. 
Hash functions such as MD5 and SHA-1 are generally known to execute faster in software 
than symmetric block ciphers such as DES-CBC. There has been a number of proposals 
for the incorporation of a secret key into an existing hash function. MDS has been recently 
shown to be vulnerable to collision search attacks. Therefore, it seems that MD5 does 
not compromise its use within HMAC because it does not rely on a secret key. However, 
SHA-1 appears to be a cryptographically stronger function. 


7.1.3.1 HMAC Structure 


HMAC is a secret-key authentication algorithm which provides both data integrity and 
data origin authentication for packets sent between two parties. Its definition requires a 
cryptographic hash function H and a secret key K. H denotes a hash function where the 
message is hashed by iterating a basic compression function on data blocks. Let b denote 
the block length of 64 bytes or 512 bits for all hash functions such as MDS5 and SHA-1. 
h denotes the length of hash values, i.e. h = 16 bytes or 128 bits for MD5 and 20 bytes 
or 160 bits for SHA-1. The secret key K can be of any length up to b = 512 bits. 
To compute HMAC over the message, the HMAC equation is expressed as follows: 


HMAC = H[(K @ opad)|| H[(K @ ipad)||M]] 


where 


ipad = 00110110(0x36) repeated 64 times (512 bits) 
opad = 01011100(Ox5c) repeated 64 times (512 bits) 
ipad is inner padding opad is outer padding 


The following explains the HMAC equation: 


1. Append zeros to the end of K to create a b-byte string (i.e. if K = 160 bits in length 
and b = 512bits, then K will be appended with 352 zero bits or 44 zero bytes 0x00). 
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2. XOR (bitwise exclusive-OR) K with ipad to produce the b-bit block computed in 
step 1. 

3. Append M to the b-byte string resulting from step 2. 

4. Apply H to the stream generated in step 3. 

5. XOR (bitwise exclusive-OR) K with opad to produce the b-byte string computed in 
step 1. 

6. Append the hash result H from step 4 to the b-byte string resulting from step 5. 

7. Apply H to the stream generated in step 6 and output the result. 


Figure 7.2 illustrates the overall operation of HMAC-—MDS. 


Example 7.1 
HMAC-—MD5 computation using the RFC method: 


Data: Ox 2143f501 f014a713 c1059e23 7123fd68 
Key: Ox 31fa7062 c45113e3 2679fd13 53b71264 
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Figure 7.2 Overall operation of HMAC computation using either MD5 or SHA-1 (message length 
computation based on Q;||/). 
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A B C D 
IV 67452301 efcdab89 98badcfe 10325476 
H((K © ipad)||M] 4f556d1d 62d021b7 6db3 1022 00219556 
H((K © opad)]|| blce3841c 73b63dff 1a22d4bd £468e7b4 


H|(K © ipad)||M]] 
HMAC-MDS5 = 0 x b1c3841c 73b63dff 1a22d4bd £468e7b4 


The alternative operation for computation of either HMAC-—MD5 or HMAC-SHA-1 
is described in the following: 


Append zeros to K to create a b-bit string K’, where b = 512 bits. 

XOR K’' (padding with zero) with ipad to produce the b-bit block. 

Apply the compression function f(IV, K’ ® ipad) to produce (IV); = 128 bits. 
Compute the hash code A with (IV); and Mj. 

Raise the hash value computed from step 4 to a b-bit string. 

XOR K’ (padded with zeros) with opad to produce the b-bit block. 

Apply the compression function f([V, K’@opad) to produce (I[V)9 = 128 bits. 
Compute the HMAC with (IV), and the raised hash value resulting from step 5. 


20S ee 2 ho 


Figure 7.3 shows the alternative scheme based on the above steps. 


Example 7.2 
HMAC-SHA-1 computation using alternative method: 


Data: Ox 7104f218 a3192e65 1cf7025d 8011bf79 4a19 
Key: Ox 31fa7062 c45113e3 2679fd13 53b71264 


A B C D E 
IV 67452301 efcdab89 98badcfe 10325476 c3d2elf0 
SUCK @ipad), TV] = (IV);  c6edf676 ef938cee 84dd1b00 5b3be996 cb172ad4 
A[M, (IV);] f75ebdde df6b486e 796daefd e9cadc38 6bb33c7d 
SUCK @ opad), IV] = (IV), a46e7eba 64c80ca4 =c42317b3 « dd2b4fle 81c21ab0 
A[A[M, (IV)i], TV)o] ee70e949 = d7439e60 7865108b 6325235f e220024e 


HMAC-SHA-1 = 0x ee70e949 d7439e60 7865108b 6325235f e220024e 


7.2 IP Authentication Header 


The IP AH is used to provide data integrity and authentication for IP packets. It also 
provides protection against replays. The AH provides authentication for the IP header, 
as well as for upper-level protocol (TCP, UDP) data. But some IP header fields may 
change in transit and the sender may not be able to predict the value of these fields when 
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Figure 7.3 Alternative operation of HMAC computation using either MD5 or SHA-1 (message 
length computation based on M only). 


the packet arrives at the receiver. Thus, the protection provided to the IP header by AH 
is somewhat piecemeal. The AH can be used in conjunction with ESP or with the use 
of tunnel mode. Security services can be provided between a pair of hosts, between a 
pair of security gateway or between a security gateway and a host. The ESP provides 
a confidentiality service. The primary difference between the authentication provided by 
ESP and AH is the extent of the coverage. ESP does not protect any IP header fields 
unless these fields are encapsulated by ESP (tunnel mode). The current key management 
options required for both AH and ESP are manual keying and automated keying via 
IKE. Authentication is based on the use of an MAC or the Integrity Check Value (ICV) 
computation so that two hosts must share a secret key. 


7.2.1. AH Format 


The IPsec AH format is shown in Figure 7.4. The following six fields comprise the 
AH format: 


e Next header (& bits): This field identifies the type of the next payload after the AH. 
The value of this field is chosen from the set of IP numbers defined in the Internet 
Assigned Number Authority (IANA). 
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Next header Payload length Reserved 
(8 bits) (8 bits) (16 bits) 
Security Parameters Index (SPI) 
(32 bits) 





Sequence number 
(32 bits) 









Authentication data (variable) 





Figure 7.4 IPsec AH format. 


Payload length (& bits): This field specifies the length of the AH in 32-bit words, 
minus 2. The default length of the authentication data field is 96 bits, or three 32-bit 
words. With a three-word fixed header, there are a total of six words in the header, 
and the payload length field has a value of 4. 


Reserved (16 bits): This field is reserved for future use. It must be set to ‘zero’. 


SPI (32 bits): This field uniquely identifies the SA for this datagram, in combination 
with the destination IP address and security protocol (AH). 

The set of SPI values in the range 1-255 is reserved by the IANA for future 
use. The SPI value of zero (0) is reserved for local, implementation-specific use. A 
key management implementation may use the zero SPI value to mean ‘No Security 
Association Exists’ during the period when the IPsec implementation has requested 
that its key management entity establish a new SA, but the SA has not yet been 
established. 


Sequence number (32 bits): This field contains the monotonically increasing counter 
value which provides an anti-replay function. Even if the sender always transmits this 
field, the receiver need not act on it, i.e. processing of the sequence number field is 
at the discretion of the receiver. The sender’s counter and the receiver’s counter are 
initialised to zero when an SA is established. The first packet sent using a given SA 
will have a sequence number of |. The sender increments the sequence number for 
this SA and inserts the new value into the sequence number field. 

If anti-replay is enabled, the sender checks to ensure that the counter has not cycled 
before inserting the new value in the sequence number field. If the counter has cycled, 
the sender will set up a new SA and key. If the anti-replay is disabled, the sender 
does not need to monitor or reset the counter. However, the sender still increments 
the counter and when it reaches the maximum value, the counter rolls over to zero. 


Authentication data (variable): This field is a variable-length field that contains the 
Integrity Check Value (ICV) or MAC for this packet. This field must be an integral 
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multiple of 32-bit words. It may include explicit padding. This padding is included to 
ensure that the length of AH is an integral multiple of 32 bits (IPv4) or 64 bits (IPv6). 


7.2.2 AH Location 


Either AH or ESP is employed in two ways: transport mode or tunnel mode. The transport 
mode is applicable only to host implementations and provides protection for upper-layer 
protocols. In the transport mode, AH is inserted after the IP header and before an upper- 
layer protocol (TCP, UDP or ICMP), or before any other IPsec header that may have 
already been inserted. 

In the IPv4 context, AH is placed after the original IP header and before the upper-layer 
protocol TCP or UDP. Note that an ICMP message may be sent using either the transport 
mode or the tunnel mode. Authentication covers the entire packet, excluding mutable 
fields in the IPv4 header that are set to zero for MAC computation. The positioning of 
AH transport mode for an IPv4 packet is illustrated in Figure 7.5(a). 

In the IPv6 context, AH should appear after hop-to-hop, routing and fragmentation 
extension headers. The destination options extension header(s) could appear either before 
or after AH, depending on the semantics desired. Authentication again covers the entire 
packet, excluding mutable fields that are set to zero for MAC computation. The positioning 
of AH transport mode for an IPv6 packet is illustrated in Figure 7.5(b). 

Tunnel mode AH can be employed in either hosts or security gateways. When AH is 
implemented in a security gateway to protect transit traffic, tunnel mode must be used. In 
tunnel mode, the inner IP header carries the ultimate source and destination addresses, 
while an outer IP header may contain different IP addresses (i.e. addresses of firewalls or 
other security gateways). In tunnel mode, AH protects the entire inner IP packet, including 
the entire inner IP header. The position of AH in tunnel mode, relative to the outer IP 
header, is the same as for AH in transport mode. Figure 7.5(c) illustrates AH tunnel mode 
positioning for typical IPv4 and IPv6 packets. 


7.3 IP ESP 


The ESP header is designed to provide security services in IPv4 and IPv6. ESP can be 
applied alone, in combination with the IP AH or through the use of tunnel mode. Security 
services are provided between a pair of hosts, between a pair of security gateways or 
between a security gateway and a host. 

The ESP header is inserted after the IP header and before the upper-layer protocol 
header (transport mode) or before an encapsulated IP header (tunnel mode). 

ESP is used to provide confidentiality (encryption), data authentication, integrity and 
anti-replay service, and limited traffic flow confidentiality. Confidentiality could be selec- 
ted independent of all other services. However, use of confidentiality without integrity/ 
authentication may subject traffic to certain forms of active attacks that undermine the con- 
fidentiality service. Data authentication and integrity are joint services offered as an option 
with confidentiality. The anti-replay service is chosen only if data origin authentication 


254 


IPv4 


IPv4 


IPv6 


IPv6 


IPv4 


IPv6 


orig IP hdr 
(any options) 


INTERNET SECURITY 


TCP 


Data 





Before applying AH 


¢— Authenticated except for mutable fields —| 








orig IP hdr 
(any options) oH 
After applying AH 


TCP 


(a) AH transport mode for an IPv4 packet 


Data 




















: ext hdrs 
orig IP hdr (if any) TCP Data 
Before applying AH 


¢— Authenticated except for mutable fields ——————» 





























; hop-by-hop, dest, 
orig IP hdr routing, fragment AH dest TCP Data 
After applying AH 


(b) AH transport mode for an IPv6 packet 


¢— Authenticated except for mutable fields in the new IP hdr ——> 





new IP hdr 





AH 





orig IP hdr 





TCP 





Data 








¢— Authenticated except for mutable fields in the new IP hdr and its extension headers 





new IP hdr 








ext 
hdrs 





AH 





orig IP 
header 





ext 
headers 


TCP 





Data 








(c) AH tunnel mode for typical IPv4 and IPv6 packets 


Figure 7.5 Transport mode and tunnel mode for AH authentication. 


is selected and the service is effective only if the receiver checks the sequence number. 
The current key management options required for both AH and ESP are manual keying 
and automated keying via IKE. 


7.3.1 


ESP Packet Format 


Figure 7.6 shows the format of an ESP packet and the fields in the header format are 
defined in the following. 


NETWORK LAYER SECURITY 255 





Security Parameters Index (SPI) 
(32 bits) 





Security number 
(32 bits) 





Payload data (variable) 
Plaintext = 


Payload data || Padding || 
Pad length || Next header 





Padding (0-255 bytes) 











Nest header = multiple number of 4 bytes 


(8 bits) 





Pad length 














Authentication data (variable) 








Figure 7.6 IPsec ESP format. 


SPI (32 bits): The SPI is an arbitrary 32-bit value that uniquely identifies an SA for 
this datagram. The set of SPI values in the range 1-255 is reserved by the IANA for 
future use. The SPI field in the ESP packet format is mandatory and always present. 


Sequence number (32 bits): This field contains a monotonically increasing counter 
value. This provides an anti-replay function. It is mandatory and is always present 
even if the receiver does not elect to enable the anti-replay service for a specific SA. 
If anti-replay is enabled, the transmitted sequence number must not be allowed to 
cycle. Thus, the sender’s counter and the receiver’s counter must be reset prior to the 
transmission of the 2**nd packet on an SA. 


Payload data (variable): This variable-length field contains data described by the next 
header field. The field is an integral number of bytes in length. If the algorithm requires 
an initialisation vector (IV) to encrypt payload, then this data may be carried explicitly 
in the payload field. Any encryption algorithm that requires such IP data must indicate 
the length, structure and location of this data by specifying how the algorithm is used 
with ESP. For some IP-based modes of operation, the receiver treats the IP as the 
start of the ciphertext, feeding it into the algorithm directly. 


Padding: This field for encryption requires several factors: 


— If an encryption algorithm requires the plaintext to be a multiple number of bytes, 
the padding field is used to fill the plaintext to the size required by the algorithm. 
The plaintext consists of the payload data, pad length and next header field, as 
well as the padding (see Figure 7.6) 

— Padding is also required to ensure that the ciphertext terminates on a 32-bit 
boundary. Specifically, the pad length and next header fields must be right aligned 
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within a 32-bit word to ensure that the authentication data field is aligned on a 
32-bit boundary. 

The sender may add 0-255 bytes of padding. Inclusion of the padding field in 
an ESP packet is optional, but all implementations must support the generation and 
consumption of padding. For the purpose of ensuring that either the bits to be encrypted 
are a multiple of the algorithm’s blocksize or the authentication data is aligned on a 
32-bit boundary, the padding is applied to the payload data exclusive of the IV, the 
pad length and next header fields. 

The padding bytes are initialised with a series of integer values such that the first 
padding byte appended to the plaintext is numbered 1, with subsequent padding bytes 
following a monotonically increasing sequence: 1, 2, 3, .... When this padding scheme 
is employed, the receiver should inspect the padding field. Any encryption algorithm 
requiring padding must define the padding contents, while any required receiver must 
process these padding bytes in specifying how the algorithm is used with ESP. In 
such circumstances, the encryption algorithm and mode selected will determine the 
content of the padding field. Subsequently, a receiver must inspect the padding field 
and inform senders of how the receiver will handle the padding field. 


Pad length: This field indicates the number of pad bytes immediately preceding it. 
The range of valid values is 0-255, where a value of 0 indicates that no padding 
bytes are present. This field is mandatory. 


Next header (8 bits): This field identifies the type of data contained in the payload 
data field, i.e. an extension header in IPv6 or an upper-layer protocol identifier. The 
value of this field is chosen from the set of IP numbers defined by the IANA. The 
next header field is mandatory. 


Authentication data (variable): This is a variable-length field containing an ICV com- 
puted over the ESP packet minus the authentication data. The length of this field is 
specified by the authentication function selected. The field is optional and is included 
only if the authentication service has been selected for the SA in question. The authen- 
tication algorithm must specify the length of the ICV and the comparison rules and 
processing steps for validation. 


7.3.2 ESP Header Location 


Like AH, ESP is also employed in the two transport or tunnel modes. The transport mode 
is applicable only to host implementations and provides protection for upper protocols, 
but not the IP header. In the transport mode, ESP is inserted after the IP header and 
before an upper-layer protocol (TCP, UDP or ICMP), or before any other IPsec headers 
that have already been inserted. 


In the IPv4 context, ESP is placed after the IP header, but before the upper-layer 


protocol. Note that an ICMP message may be sent using either the transport mode or the 
tunnel mode. Figure 7.7(a) illustrates ESP transport mode positioning for a typical IPv4 
packet, on a before and after basis. The ESP trailer encompasses any padding, plus the 
pad length, and next header fields. 
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(c) ESP tunnel mode for typical IPv4 and IPv6 packets 


Figure 7.7 Transport mode and tunnel mode for ESP authentication. 
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In the IPv6 context, the ESP appears after hop-by-hop, routing and fragmentation 
extension headers. The destination options extension header(s) could appear either before 
or after the ESP header depending on the semantics desired. However, since ESP protects 
only fields after the ESP header, it is generally desirable to place the destination options 
header(s) after the ESP header. Figure 7.7(b) illustrates ESP transport mode positioning 
for a typical IPv6 packet. 

Tunnel mode ESP can be employed in either hosts or security gateways. When ESP is 
implemented in a security gateway to protect subscriber transit traffic, tunnel mode must 
be used. In tunnel mode, the inner IP header carries the ultimate source and destination 
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addresses, while an outer IP header may contain different IP addresses such as addresses 
of security gateways. In tunnel mode, ESP protects the entire inner IP packet, including 
the entire inner IP header. The position of ESP in tunnel mode, relative to the outer IP 
header, is the same as for ESP in transport mode. Figure 7.7(c) illustrates ESP tunnel 
mode positioning for typical IPv4 and IPv6 packets. 


7.3.3 Encryption and Authentication Algorithms 


ESP is applied to an outbound packet associated with an SA that calls for ESP process- 
ing. The encryption algorithm employed is specified by the SA, as is the authentication 
algorithm. 


7.3.3.1 Encryption 


ESP is designed for use with symmetric algorithms like a triple DES in CBC mode. How- 
ever, a number of other algorithms have been assigned identifiers in the DOI document. 
These algorithms for encryption are: RC5, IDEA, CAST and Blowfish. 

For encryption to be applied, the sender encapsulates the ESP payload field, adds any 
necessary padding, and encrypts the result (i.e. payload data, padding, pad length and 
next header). The sender encrypts the fields (payload data, padding, pad length and next 
header) using the key, encryption algorithm, algorithm mode indicated by the SA and an 
IV (cryptographic synchronisation data). If the algorithm to be encrypted requires an IV, 
then this data is carried explicitly in the payload field. The payload data field is an integral 
number of bytes in length. Since ESP provides padding for the plaintext, encryption 
algorithms employed by ESP exhibit either block or stream mode characteristics. 

The encryption is performed before the authentication and does not encompass the 
authentication data field. The order of this processing facilitates rapid detection and rejec- 
tion of replayed or bogus packets by the receiver, prior to decrypting the packet. Therefore, 
it will reduce the impact of service attacks. At the receiver, parallel processing of packets 
is possible because decryption can take place in parallel with authentication. Since the 
authentication data is not protected by encryption, a keyed authentication algorithm must 
be employed to compute the ICV. 

Referring to Figure 7.8, the 3DES—CBC mode requires an IV that is the same size 
as the block size. The IV is XORed with the first plaintext block before it is encrypted. 
For successive blocks, the previous ciphertext block is XORed with the current plaintext 
before it is encrypted. Triple DES, known as DES—EDE3, processes each block three 
times, each time with a different key. Therefore, the triple DES algorithm has 48 rounds. 
In DES—EDE3-CBC, an IV is XORed with the first 64-bit plaintext block (P1). 

Some cipher algorithms allow for a variable-sized key (RC5), while others only allow 
a specific key size (DES, IDEA). 


7.3.3.2 Decryption 


The receiver decrypts the ESP payload data, padding, pad length and next header using the 
key, encryption algorithm, algorithm mode and IV data. If explicit IV data is indicated, it 
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Figure 7.8 DES—EDE3-CBC algorithm. 


is taken from the payload field and input to the decryption algorithm. If implicit IV data is 
indicated, a local version of the IV is constructed and input to the decryption algorithm. 

The exact steps for reconstructing the original datagram depend on the mode (transport 
or tunnel) and are described in the Security Architecture document. The receiver processes 
any padding as given in the encryption algorithm specification. For transport mode, the 
receiver reconstructs the original IP datagram from the original IP header plus the original 
upper-layer protocol information in the ESP payload field. For tunnel mode, the receiver 
reconstructs the tunnel IP header plus the entire IP datagram in the ESP payload field. 

If authentication has been computed, verification and decryption are performed serially 
or in parallel. If performed serially, then ICV or MAC verification should be performed 
first. If performed in parallel, verification must be completed before the decrypted packet 
is passed on for further processing. This order of processing facilitates rapid detection 
and rejection of replayed or bogus packets by the receiver. 


7.3.3.3 Authentication 


The authentication algorithm employed for the ICV computation is specified by the SA. 
For communication between two points, suitable authentication algorithms include Keyed 
Message Authentication Codes (MACs) based on symmetric encryption algorithms (i.e. 
DES) or on one-way hash function (i.e. MD5 or SHA-1). For multicast communication, 
one-way hash algorithms combined with asymmetric signature algorithms are appropriate. 
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If authentication is selected for the SA, the sender computes the ICV over the ESP 
packet minus the authentication data. As stated previously, the fields of payload data, 
padding, pad length and next header are all in ciphertext form because encryption is 
performed prior to authentication. Thus, the SPI, sequence numbers and these four fields 
are all encompassed by the ICV computation. 


7.3.3.4 ICV 


Once the SA selects the authentication algorithm, the sender computes the ICV over the 
ESP packet minus the authentication data. The ICV is an MAC or a truncated value of a 
code produced by an MAC algorithm. As with AH, ESP supports the use of an MAC with 
a default length of 96 bits. The current specification for use of the HMAC computation 
must support: 


HMAC-MD5-96 
HMAC-SHA-1-96 


7.4 Key Management Protocol for IPsec 


The key management mechanism of IPsec involves the determination and distribution of a 
secret key. Key establishment is at the heart of data protection that relies on cryptography. 
A secure key distribution for the Internet is an essential part of packet protection. 

Prior to establishing a secure session, the communicating parties need to negotiate the 
terms that are defined in the SA. An automated protocol is needed in order to establish 
the SAs for making the process feasible on the Internet. This automated process is the 
IKE. IKE combines ISAKMP with the Oakley key exchange. 

We begin our discussion with an overview of Oakley and then look at ISAKMP. 


7.4.1. OAKLEY Key Determination Protocol 


The Diffie-Hellman key exchange algorithm provides a mechanism that allows two users 
to agree on a shared secret key without requiring encryption. This shared key is immedi- 
ately available for use in encrypting subsequent data transmission. Oakley is not only a 
refinement of the Diffie-Hellman key exchange algorithm, but a method to establish an 
authentication key exchange. The Oakley protocol is truly used to establish a shared key 
with an assigned identifier and associated authenticated identities for the two parties. Oak- 
ley can be used directly over the IP protocol or over UDP protocol using a well-known 
port number assignment available. 

It is worth to note that Oakley uses the cookies for two purposes: anti-clogging (denial 
of service) and key naming. The anti-clogging tokens provide a form of source address 
identification for both parties. The construction of the cookies prevents an attacker from 
obtain a cookie using a real IP address and UDP port. 

Creating the cookie is to produce the result of a one-way function applied to a secret 
value, the IP source and destination addresses, and the UDP source and destination ports. 
Protection against the anti-clogging always seems to be one of the most difficult to address. 
A cookie or anti-clogging token is aimed for protecting the computing resources from 
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attack without spending excessive CPU resources to determine its authenticity. Absolute 
protection against anti-clogging is impossible, but this anti-clogging token provides a 
technique for making it easier to handle. 

Oakley employs nonces to ensure against replay attacks. Each nonce is a pseudorandom 
number which is generated by the transmitting entity. The nonce payload contains this 
random data used to guarantee liveness during a key exchange and protect against replay 
attacks. If nonces are used by a particular key exchange, the use of the nonce payload 
will be dictated by the key exchange. The nonces may be transmitted a part of the key 
exchange data. 

All the Oakley message fields correspond to ISAKMP message payloads. The relevant 
payload fields are the SA payload, the authentication payload, the certification payload, 
and the exchange payload. Oakley is the actual instantiation of ISAKMP framework for 
IPsec key and SA generation. The exact mapping of Oakley message fields to ISAKMP 
payloads is in progress at this time. 


7.4.2 ISAKMP 


ISAKMP defines a framework for SA management and cryptographic key establishment 
for the Internet. This framework consists of defined exchange, payloads and processing 
guidelines that occur within a given DOI. ISAKMP defines procedures and packet formats 
to establish, negotiate, modify and delete SAs. It also defines payloads for exchanging key 
generation and authentication data. These payload formats provide a consistent framework 
for transferring key and authentication data which is independent of the key generation 
technique, encryption algorithm and authentication mechanism. 

ISAKMP is intended to support the negotiation of SAs for security protocols at all 
layers of the network stack. By centralising the management of the SAs, ISAKMP reduces 
the amount of duplicated functionality within each security protocol. 


(I) ISAKMP Payloads 


ISAKMP payloads provide modular building blocks for constructing ISAKMP messages. 
The presence and ordering of payloads in ISAKMP is defined by and dependent upon the 
Exchange Type Field located in the ISAKMP Header. 


ISAKMP Header 
The ISAKMP header fields are fined as shown in Figure 7.9. 


¢ Initiator Cookie (64 bits) 
This field is the cookie of entity that initiated SA establishment, SA notification, or 
SA deletion. 

+ Responder Cookie (64 bits) 
This field is the cookie of entity that is corresponded to an SA establishment request, 
SA notification, or SA deletion. 

+ Next Payload (8 bits) 
This field indicates the type of the first payload in the message. 
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Figure 7.9 ISAKMP header format. 


Major Version (4 bits) 

This field indicates the Major version of the ISAKMP protocol in use. Set the Major 
version to 1 according to ISAKMP Internet-Draft. 

Minor Version (4 bits) 

This field indicates the Minor version of ISAKMP protocol in use. Set the Minor 
version to 0 according to implementations based on the ISAKMP Internet-Draft. 
Exchange Type (8 bits) 

This field indicates the type of exchange being used. This dictates the message and 
payload orderings in the ISAKMP exchanges. 

Flags (8 bits) 

This field indicates specific options that are set for the ISAKMP exchange. The Flags 
are specified in the Flags field beginning with the least significant bit: the encryption 
bit is bit 0 of the Flags field, the commit bit is bit 1, and authentication only bit is 
bit 2 of the Flags field. The remaining bits of the Flags field must be set to 0 prior to 
transmission. 


— All payloads following the header are encrypted using the encryption algorithm 
identified in the ISAKMP SA. The encryption should begin after both parties have 
exchanged Key Exchange payloads. 

— The commit bit is used to signal key exchange synchronization. In addition to 
synchronizing key exchange, the commit bit can be used to protect against loss 
of transmissions over unreliable networks and guard against the need for multiple 
retransmissions. 

— Authentication only bit is intended for use with the information exchange with 
a notify payload and will allow the transmission of information with integrity 
checking, but no encryption. 
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+ Message ID (32 bits) 
Message ID is used to identify protocol state during Phase 2 negotiations. This value 
is randomly generated by the initiator of the phase 2 negotiation. During Phase 1 
negotiation, this value must be set to 0. 

+ Length (32 bits) 
Length of total message (header || payload) is 32 bits. Encryption can expand the size 
of an ISAKMP message. 


Generic Payload Header 


Each ISAKMP payload begins with a generic header which provides a payload chaining 
capability and clearly defines the boundaries of a payload. 
The generic payload header fields in 32 bits are defined as follows: 


+ Next Payload (8 bits) 
This field is identifier for the payload type of the next payload in the message. If the 
current payload is the last in the message, then this field will be 0. This field provides 
the chaining capability. 

+ Reserved (8 bits) 
This field is not used and set to 0. 

¢ Payload Length (16 bits) 
This field indicates the length in bytes of the current payload, including the generic 
payload header. 


(II) Payload Types for ISAKMP 


ISAKMP defines several types of payloads that are used to transfer information such as 
SA data or key exchange data in DOI-defined formats. RFC 2408 presents by Maughan, 
et al.is good coverage of ISAKMP payloads. 


Security Association Payload 


The Security Association Payload is used to negotiate security attirutes and to identify 
the Domain of Interpretation (DOI, 32 bits) under which negotiation is taking place. A 
DOI value of 0 during a Phase 1 exchange specifies a Generic ISAKMP which can be 
used for any protocol during the Phase 2 exchange. A DOI value of | is assigned to the 
IPsec DOI. 

The Security Association Payloads are defined as follows: 


The Next Payload field (8 bits) is the identifier for the payload type of the next payload 
in the message. This field has a value of 0 if this is the last payload in the message. 


The Reserved field (8 bits) is unused, set to 0. 
The Payload Length field (16 bits) indicates the length in octets of the entire Security 


Association payload, including the SA payload, all Proposal payloads, and all Transform 
payloads associated with the proposed SA. 
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The Situation field (variable length) is a DOI-specific field that identifies the situation 
under which negotiation is taking a place. The Situation field defines policy decisions 
regarding the security attributes being negotiated. 


Proposal Payload 


The Proposal Payload is used to build ISAKMP message for the negotiation and establish- 
ment of SAs. The Proposal Payload field contains information used during SA negotiation 
for securing the communications channel. The payload type for the Proposal Payload 
is two(2). 

The Proposal Payload fields are defined as follows: 


The Next Payload field (8 bits) is the identifier for the payload type of the next payload 
in the message. This field must only contain the value 2 or 0. This field will be 2 for 
additional Proposal Payloads in the message and 0 when the current Proposal Payload is 
the last within the SA proposal. 


The Reserved field (8 bits) is set to 0 and is reserved it for the future use. 


The Payload Length field (16bits) is the length in octets of the entire Proposal pay- 
load, including generic payload header, the Proposal Payload, and all Transform payloads 
associated with this proposal. 


The Proposal # field (8 bits) identifies the proposal number for the current payload. 


The Protocol-id field (8 bits) specifies the protocol identifier for the current negotiation. 
Examples might include IPsec ESP, IPsec AH, OSPF, TLS, etc. 


The SPI Size (8 bits) denotes the length in octets of the SPI. In the case of ISAKMP, the 
Initiator and Responder cookie pair from the ISAKMP Header is the ISAKMP SPI. The 
SPI size may be from zero(0) to sixteen (16). If the SPI size is non-zero, the content of 
the SPI field must be ignored. The DOI will dictate the SPI Size for other protocols. 


# of Transform (8 bits) specifies the number of transforms for the proposal. Each of these 
is contained in a Transform Payload. 


SPI field (variable) is the sending entity’s SPI. In the event of the SPI size is not a multiple 
of 4 octets, there is no padding applied to the payload. 


Transform Payload 


The Transform Payload contains information used during Security Association negotiation. 
The Transform Payload consists of a specific security mechanism to be used to secure the 
communications channel. The Transform Payload also contains the security association 
attributes associated with the specific transform. These SA attributes are DOI-specific. 
The Transform Payload allows the initiating entity to present several possible supported 
transforms for that proposed protocol. 

The Transform Payload field s are defined as follows: 


The Next Payload field (8 bits) is the identifier for the payload type of the next payload in 
the message. This field must only contain the value 3 or 0. This field is 3 when there are 
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additional Transform payloads in the proposal. This field is 0 when the current Transform 
Payload is the last within the proposal. 


The Reserved field (8 bits) is for unused, set to 0. 


The Transform # field (8 bits) identifies the Transform number for the current payload. 
If there is more than one transform within the Proposal Payload, then each Transform 
Payload has a unique Transform number. 


The Transform-id field (8 bits) specifies the Transform identifier for the protocol within 
the current proposal. 


The Reserved 2 field (16 bits) is for unused, set to 0. 


The SA Attributes field (variable length) contains the security association (SA) attributes 
as defined for the transform given in the Transform-id field. The SA Attributes should be 
represented using the Data Attributes format. These Data Attributes are not an ISAKMP 
payload, but are contained within ISAKMP payloads. The format of the Data Attributes 
provides the flexibility for representation of many different types of information. There 
may be multiple Data Attributes within a payload. The length of the Data Attributes 
will either be 4 octets or defined by the Attribute Length field (16bits). If the SA 
Attributes are not aligned on 4-byte boundaries, then subsequent payloads will not be 
aligned and any padding will be added at the end of the message to make th message 
4-byte aligned. 


The payload type for the Transform Payload is three (3). 


Key Exchange Payload 


The Key Exchange Payload supports a variety of key exchange techniques. Example 
key exchanges are Oakley, Diffie-Hellman, the enhanced D-H key exchange, and the 
RSA-based key exchange used by PGP. 

The Key Exchange Payload fields are defined as follows: 


The Next Payload field (8 bits) is the identifier for the payload type of the next payload 
in the message. If the current payload is the last in the message, then this field will be 0. 


The Reserved field (8 bits) is unused for the future use, set to 0. 


The Payload Length field (16 bits) is the length in octets of the current payload, including 
the generic payload header. 

The Key Exchange Data field (variable length) is the data required to generate a ses- 
sion key. The interpretation of this data is specified by the DOI and the associated Key 
Exchange algorithm. This field may also contain pre-placed key indicators. 


Identification Payload 


The Identification Payload contains DOI-specific data used to exchange identification 
information. This information is used for determining the identities of communication 
partners and may be used for determining authenticity of information. 
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The Identification Payload fields are described as follows: 


The Next Payload field (8 bits) is the identifier for the payload type of the Next Payload 
in the message. If the current payload is the last in the message, then this field will be 0. 
The Reserved field (8 bits) is not used, but set to 0. 

The Payload Length field (16 bits) is the length in octets of the current payload, including 
the generic payload header. 

The ID type field (8 bits) specifies the type of identification being used. This field is 
DOI-dependent. 

The DOI specific ID Data field (24 bits) contains DOI specific identification data. If 
unused, then this field must be set to 0. 


The Identification Data field (variable length) contains identity information. The values 
for this field are DOI-specific and the format is specified by the ID Type field. Specific 
details for the IETF IPsec DOI identification data are detailed in RFC 2407. 


The payload type for the Identification Payload is five(5). 


Certificate Payload 


The Certificate Payload provides a mean to transport certificates via ISAKMP and can 
appear in any ISAKMP message. Certificate payloads should be included in an exchange 
whenever an appropriate directory service is not available to distribute certificates. The 
Certificate payload must be accepted at any point during an exchange. 

The Certificate Payload fields are defined as follows: 


The Next Payload field (8 bits) is the identifier for the Payload type of the next payload 
in the message. If the current payload is the last in the message, then this field will be 0. 


The Reserved field (8 bits) is unused, set to 0. 
The Payload Length field (16 bits) is the length in octets of the current payload, including 
the generic payload header. 


The Certificate Encoding field (8 bits) indicates the type of certificate or certificate-related 
information contained in the Certificate Data field. 


Certificate Type Value 
NONE 0 
PKCS #7 wrapped X.509 certificate 1 
PGP Certificate 2 
DNS Signed Key 3 
X.509 Certificate-Signature 4 
X.509 Certificate-Key Exchange 5 
Kerberos Tokens 6 
Certificate Revocation List (CRL) 7 
Authority Revocation List (ARL) 8 
SPKI Certificate 9 
X.509 Certificate-Attribute 10 


Reserved 11-255 
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The Certificate Data field (variable length) denotes actual encoding of certificate data. 
The type of certificate is indicated by the Certificate Encoding field. 


The Payload type for the Certificate payload is six(6). 


Certificate Request Payload 


The Certificate Request Payload provides a mean to request certificate via ISAKMP 
and can appear in any message. Certificate Request Payloads should be included in an 
exchange whenever an appropriate directory service is not available to distribute certifi- 
cates. The Certificate Request Payload must be accepted at any point during the exchange. 
The responder to the Certificate Request payload must send its certificate, if certificates 
are based on the values contained in the payload. If multiple certificates are required, then 
multiple Certificate Request Payloads should be transmitted. 
The Certificate Request Payload fields are defined as follows: 


The Next Payload field (8 bits) is the identifier for the payload type of the next payload 
in the message. If the current payload is the last in the message, then this field will be 0. 


The Reserved field (8 bits) is not used, set to 0. 


The Payload Length field (16 bits) is the length in octets of the current payload, including 
the generic payload header. 


The Certificate Type field (8 bits) contains an encoding of the type of certificate requested. 
Acceptable values are listed in the Certificate Payload fields. 


The Certificate Authority field (variable length) contains an encoding of an acceptable 
certificate authority for the type of certificate requested. As an example, for an X.509 
certificate this field would contain the Distinguished Name encoding of the Issuer Name 
of an X.509 certificate authority acceptable to the sender of this payload. This may assist 
the responder in determining how much of the certificate chain would need to be sent in 
response to this request. If there is no specific certificate authority requested, this field 
should not be included. 


The payload type for the Certificate Request Payload is seven(7). 


Hash Payload 


The Hash Payload contains data generated by the hash function over some part of the 
message and/or ISAKMP state. This payload possibly be used to verify the integrity of 
the data in an ISAKMP message or for authentication of the negotiating entities. 

The Hash Payload fields are defined as follows: 


The Next Payload field (8 bits) is the identifier for the payload type of the next payload 
in the message. If the current payload is the last in the message, then this field will be 0. 


The Reserved field (8 bits) is not used, set to 0. 


The Payload Length field (16 bits) is the length in octets of the current payload, including 
the generic payload header. 
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The Hash Data field (variable length) is the data that results from applying the hash 
routine to the ISAKMP message and/or state. 


The payload type for the Hash Payload is eight(8). 


Signature Payload 


The Signature Payload contains data generated by the digital signature function, over some 
part of the message and/or ISAKMP state. This payload is used to verify the integrity of 
the data in the ISAKMP message, and may be of use for non-repudiation services. 

The Signature Payload fields are defined as follows: 


The Next Payload field (8 bits) is the identifier for the payload type of the next payload 
in the message. If the current payload is the last in the message, then this field will be 0. 
The Reserved field (8 bits) is not used, but set to 0. 

The Payload Length field (16 bits) is the length in octets of the current payload, including 
the generic payload header. 

The Signature Data field (variable length) is the data that results from applying the digital 
signature function to the ISAKMP message and/or state. 

The payload type for the Signature Payload is nine(9). 


Nonce Payload 


The Nonce Payload contains random data used to guarantee liveness during an exchange 
and protect against replay attacks. If nonce are used by a particular key exchange, the use 
of the Nonce Payload wil be dictated by the key exchange. The nonces may be transmitted 
as part of the key exchange data, or as a separate payload. However, this is defined by 
the key exchange, not by ISAKMP. 

The Nonce Payload fields are defined as follows: 


The Next Payload field (8 bits) is the identifier for the payload type of the next payload 
in the message. If the current payload is the last in the message, then this field will be 0. 


The Reserved field (8 bits) is unused, but set to 0. 


The Payload Length field (16 bits) is the length in octets of the current payload, including 
the generic payload header. 

The Nonce Data field (variable length) contains the random data generated by the trans- 
mitting entity. 

The Payload type for the Nonce Payload is ten(10). 


Notification Payload 


The Notification Payload can contain both ISAKMP and DOlI-specific data and is used 
to transmit information data, such as error conditions to an ISAKMP peer. It is possible 
to send multiple Notification Payloads in a single ISAKMP message. Notification which 
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occurs during a Phase | negotiation is identified by the Initiator and Responder cookie 
pair in the ISAKMP Header. Notification which occurs during a Phase 2 negotiation is 
identified by the Initiator and Responder cookie pair in the ISAKMP header and the 
Message ID and SPI associated with the current negotiation. 

The Notification Payload fields are defined as follows: 


The Next Payload field (8 bits) is the identifier for the payload type of the next payload 
in the message. If the current payload is the last in the message, then this field will be 0. 


The Reserved field (8 bits) is unused, but set to 0. 


The Payload Length field (16 bits) is the length in octets of the current payload, including 
the generic payload header. 


The Domain of Interpretation field (32 bits) identifies the DOI under which this notification 
is taking place. For ISAKMP this value is zero(0) and for the IPsec DOI it is one (1). 


The Protocol-id field (8 bits) specifies the protocol identifier for the current notification. 
Examples might include ISAKMP, IPsec ESP, IPsec AH, OSPF, TLS, etc. 


The SPI Size field (8 bits) is the length in octets of the SPI as defined by the protocol- 
id. In the case of ISAKMP, the Initiator and Responder cookie pair from the ISAKMP 
Header is the ISAKMP SPI. Therefore, the SPI size is irrelevant and may be from zero(0) 
to sixteen(16). If the SPI size is non-zero, the content of the SPI field must be ignored. 
The Domain of Interpretation (DOI) will dictate the SPI size for other protocols. 


The Notify Message Type field (16 bits) specifies the type of notification message. Addi- 
tional text, if specified by the DOI, is placed in the Notification Data field. 


The Security Parameter Index (SPI) field has the variable length. The length of this field 
is determined by the SPI Size field and is not necessarily aligned to a 4-octet boundary. 
During the SA establishment, a SPI must be generated. ISAKMP is designed to handle 
variable sized SPIs. This is accomplished by using the SPI Size field within the Proposal 
payload during SA establishment. 


The Notification Data field (variable length) is informational or error data transmitted in 
addition to the Notify Message Type. Values for this field are DOI-specific. 
The payload type for the Notification Payload is eleven (11). 


Delete Payload 


The Delete Payload contains a protocol-specific security association identifier that the 
sender has removed from its SA database. Therefore, the sender is no longer valid. It 
is possible to send multiple SPIs in a Delete Payload. But each SPI must be for the 
same protocol. 

The Delete Payload fields are defined as follows: 


The Next Payload field (8 bits) is the identifier for the payload type of the next payload 
in the message. If the current payload is the last in the message, then this field will be 0. 
The Reserved field (8 bits) is unused, but set to 0. 


The Payload Length field (16 bits) is the length in octets of the current payload, including 
the generic payload header. 
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The Domain of Interpretation field (32 bits) identifies the DOI under which this deletion 
is taking place. For ISAKMP this value is zero(O) and for the IPsec DOI it is one (1). 


The Protocol-id field (8 bits) specifies that ISAKMP can establish SAs for various proto- 
cols, including ISAKMP and IPsec. This field identifies which SA database to apply the 
delete request. 


The SPI Size field (8 bits) is the length in octets of the SPI as defined by the Protocol-id. 
In the case of ISAKMP, the Initiator and Responder cookie pair is the ISAKMP SPI. In 
this case, the SPI Size would be 16 bytes for each SPI being deleted. 


The # of SPIs field (16 bits) is the number of SPIs contained in the Delete Payload. The 
size of each SPI is defined by the SPI Size field. 


The Security Parameter Indexes field (variable length) identifies the specific security 
associations to delete. Values for this field are DOI and protocol specific. The length of 
this field is determined by the SPI Size and # of SPIs fields. 


The Payload type for the Delete Payload is twelve(12). 


Vendor ID Payload 


The Vendor ID Payload contains a vendor defined constant. The constant is used by ven- 
dors to identify and recognize remote instances of their implementations. This mechanism 
allows a vendor to experiment with new features while maintaining backwards compati- 
bility. However, this is not a general extension facility of ISAKMP. 

If a Vendor ID payload is sent, it must be sent during the Phase | negotiation. Reception 
of a familiar Vendor ID Payload in the Phase 1 negotiation allows an implementation to 
make use of Private Use payload numbers for vendor specific extension during Phase 2 
negotiation. 

The Vendor ID Payload fields are defined as follows: 


The Next Payload field (8 bits) is the identifier for the payload type of the next payload 
in the message. If the current payload is the last in the message, then this field will be 0. 
The Reserved field (8 bits) is unused, but set to 0. 

The Payload Length field (16 bits) is the length in octets of the current payload, including 
the generic payload header. 


The Vendor ID field (variable length) contains the choice of hash and text to hash. Vendors 
could generate their vendor-id by taking a keyless hash of a string containing the product 
name, and the version of the product. 


The Payload type for the Vendor ID Payload is thirteen(13). 


(Ill) ISAKMP Exchanges 


ISAKMP supplies the basic syntax of a message exchange. ISAKMP allows the creation 
of exchanges for SA establishment and key exchange. There are currently five default 
Exchange Types defined for ISAKMP. Exchanges define the content and ordering of 
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ISAKMP messages during communications between peers. Most exchanges includes all 
the basic payload types: SA (Security Association Payload), KE (Key Exchange Payload), 
ID (identity Payload), SIG (Signature Payload), etc. The primary difference between 
exchange types is the ordering of messages and the payload ordering within each message. 

The defined exchanges are not meant to satisfy all DOI and key exchange protocol 
requirements. If the defined exchanges meet the DOI requirements, then they can be used 
as outlined. If the defined exchanges do not meet the security requirements defined by the 
DOI, then the DOI must specify new exchange type(s) and the valid sequences of payloads 
that make up a successful exchange, and how to build and interpret those payloads. 


Base Exchange 


The Base Exchange is designed to allow the Key Exchange and Authentication-related 
information to be transmitted together. Combining the Key Exchange and Authentication- 
related information into one message reduces the number of round-trips at the expense of 
not providing identity protection. 


Identity Protection Exchange 


The Identity Protection Exchange is designed to separate the Key Exchange information 
from the Identity and Authentication-related information. Separating the Key Exchange 
from the Identity and Authentication-related information provides protection of the com- 
municating identities at the expense of two additional messages. Identities are exchanged 
under the protection of a previously established common shared secret. 


Authentication Only Exchange 


The Authentication Only Exchange is designed to allow only Authentication-related infor- 
mation to be transmitted. The benefit of this exchange is the ability to perform only 
authentication without the computational expense of computing keys. Using this exchange 
during negotiation, none of the transmitted information will be encrypted. But the authen- 
tication only exchange will be encrypted by the ISAKMP SA, negotiated in the first phase. 


Aggressive Exchange 


The Aggressive Exchange is designed to allow the Security Association, Key Exchange 
and Authentication-related payloads to be transmitted together. Combining these SA, KE, 
and Auth information into one message reduces the number of round-trips at the expense 
of not providing identity protection. Identity protection is not provided because identities 
are exchanged before a common shared secret has been established. 


Informational Exchange 


The Information Exchange is designed as a one-way transmittal of information that can 
be used for security association management. If the Informational Exchange occurs prior 
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to the exchange of keying material during an ISAKMP Phase 1 negotiation, there will 
be no protection provided for the Information Exchange. Once keying material has been 
exchanged or an ISAKMP SA has been established, the Informational Exchange must be 
transmitted under the protection provided by the keying material or the ISAKMP SA. 


(IV) ISAKMP Payload Processing 


The ISAKMP payloads are used in the exchanges described in Part III above and can be 
used in exchanges defined for a specific DOI. Part IV describes the processing for each 
of the payloads. 


General Message Processing 


Every ISAKMP message has basic processing applied to insure protocol reliability and 
to minimize threats such as denial of services and replay attacks. All processing should 
include packet length checks to insure the packet received is at least as long as the 
length given in the ISAKMP Header. If the ISAKMP message length and the value in the 
Payload Length field of the ISAKMP Header are not the same, then ISAKMP message 
must be rejected. 


ISAKMP Header Processing 


When an ISAKMP message is created at the transmitting entity, the initiator (transmitter) 
must create the respective cookie, determine the relevant security characteristics of the 
session, construct an ISAKMP Header with fields, and transmit the message to the desti- 
nation host (responder). 

When an ISAKMP is received at the receiving entity, the responder (receiver) must 
verify the Initiator and Responder cookies, check the Next Payload field to confirm it is 
valid, check the Major and Minor Version fields to confirm they are correct, check the 
Exchange Type field to confirm it is valid, check the Flags field to ensure it contains 
correct values, and check the Message ID field to ensure it contains correct values. 

Thus, processing of the ISAKMP message continues using the value in the Next Pay- 
load field. 


Generic Payload Header Processing 


When any of the ISAKMP Payloads are created, a Generic Payload Header is placed at 
the beginning of these payloads. 

When creating the Generic Payload Header, the transmitting entity (initiator) must 
place the value of the Next Payload in the Next Payload field, place the value zero(0) in 
the Reserved field, place the length (in octets) of the payload in the Payload Length field, 
and construct the payloads. 

When any of the ISAKMP Payloads are received, the receiving entity (responder) must 
check the Next Payload field to confirm it is valid, verify the Reserved field contains the 
value zero(0), and process the remaining payloads as defined by the Next Payload field. 


NETWORK LAYER SECURITY 273 


Security Association Payload Processing 


When a Security Association Payload is created, the transmitting entity (initiator) must 
determine the Domain of Interpretation (DOI) for which this negotiation is being pre- 
formed, determine the situation within the determined DOI for which this negotiation is 
being formed, determine the proposal(s) and transform(s) within the situation, construct a 
Security Association payload, and transmit the message to the receiving entity (responder). 

When a Security Association payload is received, the receiving entity (responder) 
must determine if the DOI is supported, determine if the given situation can be protected, 
and process the remaining payloads (Proposal, Transform) of the SA payload. If the SA 
Proposal is not accepted, then the Invalid Proposal event may be logged in the appropriate 
system audit file. An Information Exchange with a Notification payload containing the 
No-Proposal-Chosen message type may be sent to the transmitting entity (initiator). This 
action is dictated by a system security policy. 


Proposal Paylaod Processing 


When a Proposal Payload is created, the transmitting entity (initiator) must determine 
the Protocol for this proposal, determine the number of proposals to be offered for this 
proposal and the number of transform for each proposal, generate a unique pseudo-random 
SPI, and construct a Proposal payload. 

When a Proposal payload is received, the receiving entity (responder) must determine 
if the proposal is supported and if the Protocol-ID field is invalid, determine whether the 
SPI is valid or not, ensure whether or not proposals are formed correctly, and then process 
the Proposal and Transform payloads as defined by the Next Payload field. 


Transform Payload Processing 


When creating a Transform Payload, the transmitting entity (initiator) must determine the 
Transform # for this transform, determine the number of transforms to be offered for this 
proposal, and construct a Transform payload. 

When a Transform payload is received, the receiving entity (responder) must do as 
follows: Determine if the Transform is supported. If the Transform-ID field contains an 
unknown or unsupported value, then that Transform payload must be ignored. Ensure 
Transforms are presented according to the details given in the Transform Payload and 
Security Association Establishment. Finally, process the subsequent Transform and Pro- 
posal payloads as defined by the Next Payload field. 


Key Exchange Payload Processing 


When creating a Key Exchange payload, the transmitting entity (initiator) must determine 
the Key Exchange to be used as defined by the DOI, determine the usage of Key Exchange 
Data field as defined by the DOI, and construct a Key Exchange payload. Finally, transmit 
the message to the receiving entity (responder). 
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When a Key Exchange payload is received, the receiving entity (responder) must 
determine if the Key Exchange is supported. If the Key Exchange determination fails, the 
message is discarded and the following actions are taken: 

The event of Invalid Key Information may be logged in the appropriate system audit 
file. An Informational Exchange with a Notification payload containing the Invalid-Key- 
Information message type may be sent to the transmitting entity. This action is dictated 
by a system security policy. 


Identification Payload Processing 


When an Identification Payload is created, the transmitting entity (initiator) must determine 
the Identification information to be used as defined by the DOI, determine the usage of 
the Identification Data field as defined by the DOI, construct an Identification payload, 
and finally transmit the message to the receiving entity. 

When an Identification payload is received, the receiving entity (responder) must 
determine if the Identification Type is supported. This may be based on the DOI and 
Situation. If the Identification determination fails, the message is discarded. An Infor- 
mational Exchange with a Notification payload containing the Invalid-ID-Information 
message type is sent to the transmitting entity (initiator). 


Certificate Payload Processing 


When a Certificate Payload is created, the transmitting entity (initiator) must determine the 
Certificate Encoding which is specified by the DOI, ensure the existence of a certificate 
formatted as defined by the Certificate Encoding, construct a Certificate payload, and then 
transmit the message to the receiving entity (responder). 

When a Certificate payload is received, the receiving entity (responder) must determine 
if the Certificate Encoding is supported. If the Certificate Encoding is not supported, 
the payload is discarded. The responder then process the Certificate Data field. If the 
Certificate Data is improperly formatted, the payload is discarded. 


Certificate Request Payload Processing 


When creating a Certificate Request Payload, the transmitting entity (initiator) must deter- 
mine the type of Certificate Encoding to be requested, determine the name of an acceptable 
Certificate Authority, construct a Certificate Request payload, and then transmit the mes- 
sage to the receiving entity (responder). 

When a Certificate Request payload is received, the receiving entity (responder) must 
determine if the Certificate Encoding is supported. If the Certificate Encoding is invalid, 
the payload is discarded. The responder must determine if the Certificate Authority is 
supported for the specified Certificate Encoding. If the Certificate Authority is improperly 
formatted, the payload is discarded. Finally, the responder must process the Certificate 
Request. If a requested Certificate Type with the specified Certificate Authority is not 
available, then the payload is discarded. 
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Hash Payload Processing 


When creating a Hash Payload, the transmitting entity (initiator) must determine the Hash 
function to be used as defined by the SA negotiation, determine the usage of the Hash 
Data field as defined by the DOI, construct a Hash payload, and then transmit the message 
to the receiving entity (responder). 

When a Hash Payload is received, the receiving entity (responder) must determine if 
the Hash is supported. If the Hash determination fails, the message is discarded. The 
responder also performs the Hash function as outlined in the DOI and/or Key Exchange 
protocol documents. If the Hash function fails, the message is discarded. 


Signature Payload Processing 


When a Signature Payload is created, the transmitting entity(initiator) must determine the 
Signature function to be used as defined by the SA negotiation, determine the usage of 
the Signature Data filed as defined by the DOI, construct a Signature payload, and finally 
transmit the message to the receiving entity (responder). 

When a Signature payload is received, the receiving entity must determine if the 
Signature is supported. If the Signature determination fails, the message is discarded. 
The responder must perform the Signature function as outlined in the DOI and/or Key 
Exchange protocol documents. If the Signature function fails, the message is 
discarded. 


Nonce Payload Processing 


When creating a Nonce Payload, the transmitting entity (initiator) must create a unique 
random values to be used as a nonce, construct a Nonce payload, and transmit the message 
to the receiving entity. 

When a Nonce Payload is received, the receiving entity (responder) must do as follows: 
There are no specific procedures for handling Nonce payloads. The procedures are defined 
by the exchange types and possibly the DOI and Key Exchange descriptions. 


Notification Payload Processing 


During communications it is possible that errors may occur. The Information Exchange 
with a Notify Payload provides a controlled method of informing a peer entity that occur 
has occurred during protocol processing. It is recommended that Notify Payloads be 
sent in a separate Information Exchange rather than appending a Notify Payload to an 
existing exchange. 

When a Notification Payload is created, the transmitting entity (initiator) must deter- 
mine the DOI for this Notification, determine the Protocol-ID for this Notification, deter- 
mine the SPI size based on the Protocol-ID field, determine the Notify Message Type 
based on the error or status message desired, determine the SPI which is associated with 
this notification, determine if additional Notification Data is to be included, construct a 
Notification Payload, and finally transmit the messages to the receiving entity. 
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When a Notification payload is received, the receiving entity (responder) must deter- 
mine if the Informational Exchange has any protection applied to it by checking the 
Encryption Bit and Authentication Only Bit in the ISAKMP Header, determine if the 
Domain of Interpretation (DOD) is supported, determine if the protocol-ID is supported, 
determine if the SPI is valid, determine if the Notify Message Type is valid, and then pro- 
cess the Notification payload, including additional Notification Data, and take appropriate 
action according to local security policy. 


Delete Payload Processing 


During communications it is possible that hosts may be compromised or that information 
may be interrupted during transmission. If it is discovered that transmissions are being 
compromised, then it is necessary to establish a new SA and delete the current SA. 

When a Delete Payload is created, the transmitting entity (initiator) must determine 
the DOI for this Deletion, determine the Protocol-ID for this Deletion, determine the 
SPI size based on the Protocol-id field, determine the # of SPIs to be deleted for this 
protocol, determine the SPI(s) which is (are) associated with this deletion, construct a 
Delete payload, and then transmit the message to the receiving entity. 

When a Delete payload is received, the receiving entity (responder) must do as follows: 


+ Since the Information Exchange is protected by authentication for an Auth-Only 
SA and encryption for other exchange, the message must have these security 
services applied using the ISAKMP SA. Any errors that occur during the Secu- 
rity Service processing will be evident when checking information in the Delete 
payload. 

Determine if the Domain of Interpretation (DOT) is supported. 

Delete if the Protocol-ID is supported. 

Determine if the SPI is valid for each SPI included in the Delete payload. 
Process the Delete payload and take appropriate action, according to local secu- 
rity policy. 


“ff f+ + 


The Internet Security Association and Key Management Protocol (ISAKMP) is a well 
designed protocol provided for Internet security services. ISAKMP provides the ability to 
establish SAs for multiple security protocols and applications. ISAKMP establishes the 
common base that allows all other security protocols to interoperate. 

ISAKMP’s Security Association (SA) feature coupled with authentication and key 
establishment provides the security and flexibility that will be needed for future growth 
and security diversity. As the Internet grows and evolves, new payloads to support new 
security functionality can be added without modifying the entire protocol. 


8 


Transport Layer Security: 
SSLv3 and TLSv1 


Secure Sockets Layer version 3 (SSLv3) was introduced by Netscape Communications 
Corporation in 1995. SSLeay implements both SSLv2 and SSLv3 and TLSv1 as of the 
release of SSLeay-0.9.0. SSLv3 was designed with public review and input from industry 
and was published as an Internet-Draft document. After reaching a consensus of opinion to 
Internet standardisation, the Transport Layer Security (TLS) Working Group was formed 
within IETF in order to develop an initial version of TLS as an Internet standard. The 
first version of TLS is very closely compatible with SSLv3. The TLSv1 protocol provides 
communications privacy and data integrity between two communicating parties over the 
Internet. Both the SSL and TLS protocols allow client/server applications to communicate 
in such a way that they prevent eavesdropping, tampering or message forgery. The SSL 
(or TLS) protocol is composed of two layers: the SSL (or TLS) Record Protocol and the 
SSL (or TLS) Handshake Protocol. 

This chapter is devoted to a full discussion of the protocols of both SSLv3 and TLSvl1. 


8.1 SSL Protocol 


SSL is a layered protocol. It is not a single protocol but rather two layers of protocols. 
At the lower level, the SSL Record Protocol is layered on top of some reliable transport 
protocol such as TCP. The SSL Record Protocol is also used to encapsulate various higher- 
level protocols. A higher-level protocol can layer on top of the SSL protocol transparently. 
For example, the HyperText Transfer Protocol (HTTP), which provides a transfer service 
for Web client/server interaction, can operate on top of the SSL Record Protocol. 

The SSL Record Protocol takes the upper-layer application message to be transmitted, 
fragments the data into manageable blocks, optionally compresses the data, applies an 
MAC, encrypts, adds a header, and transmits the result to TCP. The received data is 
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Figure 8.1 Two-layered SSL protocols. 


decrypted, verified, decompressed, reassembled, and then delivered to higher-level clients. 
Figure 8.1 illustrates the overview of the SSL protocol stack. 


8.1.1 Session and Connection States 


There are two defined specifications: SSL session and SSL connection. 


SSL session 


An SSL session is an association between a client and a server. Sessions are created by the 
Handshake Protocol. They define a set of cryptographic security parameters, which can be 
shared among multiple connections. Sessions are used to avoid the expensive negotiation 
of new security parameters for each connection. An SSL session coordinates the states 
of the client and server. Logically the state is represented twice as the current operating 
state and pending state. When the client or server receives a change cipher spec message, 
it copies the pending read state into the current read state. When the client or server 
sends a change cipher spec message, it copies the pending write state into the current 
write state. When the handshake negotiation is completed, the client and server exchange 
change cipher spec messages, and they then communicate using the newly agreed-upon 
cipher spec. 
The session state is defined by the following elements: 


e Session identifier: This is a value generated by a server that identifies an active or 
resumable session state. 

e Peer certificate: This is an X.509 v3 certificate of the peer. This element of the state 
may be null. 
Compression method: This is the algorithm used to compress data prior to encryption. 
Cipher spec: This specifies the bulk data encryption algorithm (such as null, DES, 
etc.) and a hash algorithm (such as MD5 or SHA-1) used for MAC computation. It 
also defines cryptographic attributes such as the hash size. 
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e Master secret: This is a 48-byte secret shared between the client and server. It repre- 
sents secure secret data used for generating encryption keys, MAC secrets and IVs. 

e Is resumable: This designates a flag indicating whether the session can be used to 
initiate new connections. 


SSL connection 


A connection is a transport (in the OSI layering model definition) that provides a suitable 
type of service. For SSL, such connections are peer-to-peer relationships. The connections 
are transient. Every connection is associated with one session. 

The connection state is defined by the following elements: 


e Server and client random: These are byte sequences that are chosen by the server and 
client for each connection. 

e Server write MAC secret: This indicates the secret key used in MAC operations on 
data sent by the server. 

e Client write MAC secret: This represents the secret key used in MAC operations on 
data sent by the client. 

e Server write key: This is the conventional cipher key for data encrypted by the server 
and decrypted by the client. 

e Client write key: 

This is the conventional cipher key for data encrypted by the client and decrypted by 
the server. 

e Initialisation vectors: When a block cipher in CBC mode is used, an IV is maintained 
for each key. This field is first initialised by the SSL Handshake Protocol. Thereafter 
the final ciphertext block from each record is preserved for use as the IV with the 
following record. The IV is XORed with the first plaintext block prior to encryption. 

e Sequence numbers: Each party maintains separate sequence numbers for transmitted 
and received messages for each connection. When a party sends or receives a change 
cipher spec message, the appropriate sequence number is set to zero. Sequence num- 
bers may not exceed 2% — 1. 


8.1.2 SSL Record Protocol 


The SSL Record Protocol provides basic security services to various higher-layer proto- 
cols. Three upper-layer protocols are defined as part of SSL: the Handshake Protocol, the 
Change Cipher Spec Protocol and the Alert Protocol. Two layers of SSL protocols are 
shown in Figure 8.1. The SSL Record Layer receives data from higher layers in blocks 
of arbitrary size. 

The SSL Record Protocol takes an application message to be transmitted, fragments the 
data into manageable blocks, optionally compresses the data, applies an MAC, encrypts, 
adds a header, and transmits the result in a TCP segment. The received data is decrypted, 
verified, decompressed, reassembled and then delivered to higher-level clients. The overall 
operation of the SSL Record Protocol is shown in Figure 8.2. 


e Fragmentation: A higher-layer message is fragmented into blocks (SSLPlaintext re- 
cords) of 2'4 bytes or less. 
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Figure 8.2 The overall operation of the SSL Record Protocol. 


Compression and decompression: All records are compressed using the compression 
algorithm defined in the current session state. The compression algorithm translates 
an SSLPlaintext structure into an SSLCompressed structure. Compression must be 
lossless and may not increase the current length by more than 1024 bytes. If the decom- 
pression function encounters an SSLCompressed.fragment that would decompress 
to a length in excess of 2'4 = 16348 bytes, it should issue a fatal decompression- 
failure alert. 

Compression is essentially useful when encryption is applied. If both compres- 
sion and encryption are required, compression should be applied before encryption. 
The compression processing should ensure that an SSLPlaintext structure is identical 
after being compressed and decompressed. Compression is optionally applied in the 
SSL Record Protocol, but, if applied, it must be done before encryption and MAC 


computation. 


MAC: The MAC is computed before encryption. The computation of an MAC over the 
compressed data is illustrated in Figure 8.3. Using a shared secret key, the calculation 


TRANSPORT LAYER SECURITY: SSLV3 AND TLSV1 





Compressed data 














MAC-write-secret | pad-1 











seq-num | SSLCompressed.type | SSLCompressed.length SSLCompressed.fragment 














Vv 





Hash algorithm MDS or SHA-1 











MAC-write-secret 





pad-2 A, 











Hash algorithm MDS or SHA-1 














Figure 8.3 Computation of MAC over the compressed data. 


is defined as follows: 


HA, = hash(MAC-write-secret || pad-1 || seq-num || SSLCompressed.type || 


SSLCompressed.length || SSLCompressed.fragment) 


H = hash(MAC-write-secret || pad-2 ||) 


where 


MAC-write-secret: 
Hash (H, and H): 


Pad-1: 


Pad-2: 


Seq-num: 


SSLCompressed.type: 


SSLCompressed.length: 


Shared secret key 

Cryptographic hash algorithm; 

either MD5 or SHA-1 

The byte 0x36 (0011 0110) repeated 
48 times (384 bits) for MD5 and 

40 times (320 bits) for SHA-1 

The byte Ox5C (0101 1100) repeated 
48 times for MD5 and 

40 times for SHA-1 

The sequence number for this message 
The higher-level protocol used to 
process this fragment 

The length of the compressed 
fragment 
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SSLCompressed.fragment: The compressed fragment (the plaintext 
fragment if not compressed) 
||: concatenation symbol 


The compressed message plus the MAC are encrypted using symmetric encryption. 
The block ciphers being used as encryption algorithms are: 


DES(56), Triple DES(168), IDEA(128), 
RCS(variable) and Fortezza(80) 


where the number inside the brackets indicates the key size. Fortezza is a PCMCIA 
card that provides both encryption and digital signing. 

For block encryption, padding is added after the MAC prior to encryption. The 
total size of the data (plaintext plus MAC plus padding) to be encrypted must be 
a multiple of the cipher’s block length. Padding is added to force the length of the 
plaintext to be a multiple of the block cipher’s block length. Padding is formed by 
appending a single ‘1’ bit to the end of the message and then ‘0’ bits are added, as 
many as needed. The last 64 bits of the total size of padded data are reserved for the 
original message length. 

For stream encryption, the compressed message plus the MAC are encrypted. Since 
the MAC is computed before encryption takes place, it is encrypted along with the 
compressed plaintext. 


e Append SSL record header: The final processing of the SSL Record Protocol is to 
append an SSL record header. The composed fields consist of: 


— Content type (8 bits): This field is the higher-layer protocol used to process the 
enclosed fragment. 
— Major version (8 bits): This field indicates the major version of SSL in use. For 
SSLv3, the value is 3. 
— Minor version (8 bits): This field indicates the minor version of SSL in use. For 
SSLv3, the value is 0. 
— Compressed length (16 bits): This field indicates the length in bytes of the plain- 
text fragment or compressed fragment if compression is required. The maximum 
value is 2'4 + 2048. 
Figure 8.4 illustrates the SSL Record Protocol format. 
The SSL-specific protocols consist of the Change Cipher Spec Protocol, the Alert 
Protocol and the Handshake Protocol, as shown in Figure 8.1. The contents of these three 
protocols are presented in what follows. 


8.1.3 SSL Change Cipher Spec Protocol 


The Change Cipher Spec Protocol is the simplest of the three SSL-specific protocols. 
This protocol consists of a single message, which is compressed and encrypted under 
the current CipherSpec. The message consists of a single byte of value 1. The change 
cipher spec message is sent by both the client and server to notify the receiving party 
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Figure 8.4 SSL Record Protocol format. 


that subsequent records will be protected under the just-negotiated CipherSpec and keys. 
Reception of this message causes the pending state to be copied into the current state, 
which updates the cipher suite to be used on this connection. The client sends a change 
cipher spec message following handshake key exchange and certificate verify messages 
(if any), and the server sends one after successfully processing the key exchange message 
it received from the client. 


8.1.4 SSL Alert Protocol 


One of the content types supported by the SSL Record Layer is the alert type. Alert 
messages convey the severity of the message and a description of the alert. Alert messages 
consist of 2 bytes. The first byte takes the value warning or fatal to convey the seriousness 
of the message. If the level is fatal, SSL immediately terminates the connection. In this 
case, other connections on the same session may continue, but the session identifiers must 
be invalidated, preventing the failed session from being used to establish new connections. 
The second byte contains a code that indicates the specific alert. As with other applications 
that use SSL, alert messages are compressed and encrypted, as specified by the current 
connection state. 
A specification of SSL-related alerts that are always fatal is listed in the following: 


e unexpected-message: An inappropriate message was received. This alert is always 
fatal. 

e bad-record-mac: This alert is returned if a record is received with an incorrect MAC. 
This message is always fatal. 

e decompression-failure: The decompression function received improper input (i.e. data 
that would expand to a length that is greater than the maximum allowable length). 
This message is always fatal. 

e no-certificate: This alert message may be sent in response to a certificate request if 
no appropriate certificate is available. 
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e bad-certificate: A received certificate was corrupt, i.e. contained a signature that did 

not verify correctly. 

unsupported certificate: The type of the received certificate is not supported. 

certificate-revoked: A certificate has been revoked by its signer. 

certificate-expired: A certificate has expired or is not currently valid. 

certificate-unknown: This means some other unspecified issue arose in processing the 

certificate, rendering it unacceptable. 

e illegal-parameter: A field in the handshake was out of range or inconsistent with 
other fields. This is always fatal. 

e close-notify: This message notifies the recipient that the sender will not send any more 
messages on this connection. The session becomes unresumable if any connection is 
terminated without proper close-notify messages with level equal to warning. Each 
party is required to send a close-notify alert before closing the write side of the 
connection. Either party may initiate a close-notify alert. Any data received after a 
closure alert is ignored. 


8.1.5 SSL Handshake Protocol 


The SSL Handshake Protocol being operated on top of the SSL Record Layer is the 
most important part of SSL. This protocol provides three services for SSL connections 
between the server and client. The Handshake Protocol allows the client/server to agree 
on a protocol version, to authenticate each other by forming an MAC, and to negotiate 
an encryption algorithm and cryptographic keys for protecting data sent in an SSL record 
before the application protocol transmits or receives its first byte of data. 

The Handshake Protocol consists of a series of messages exchanged by the client 
and server. Figure 8.5 shows the exchange of handshake messages needed to establish 
a logical connection between client and server. The contents and significance of each 
message are presented in detail in the following sections. 


8.1.5.1 Phase 1: Hello Messages for Logical Connection 


The client sends a client hello message to which the server must respond with a server 
hello message, or else a fatal error will occur and the connection will fail. The client hello 
and server hello are used to establish security enhancement capabilities between client 
and server. The client hello and server hello establish the following attributes: protocol 
version, random values (ClientHello.random and ServerHello.random), session ID, cipher 
suite and compression method. 


Hello messages 


The hello phase messages are used to exchange security enhancement capabilities between 
client and server. 


e Hello request: This message is sent by the server at any time, but may be ignored 
by the client if the Handshake Protocol is already underway. A client who receives a 
hello request while in a handshake negotiation state should simply ignore the message. 
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Figure 8.5 SSL Handshake Protocol. 


Client hello: The exchange is initiated by the client. A client sends a client hello 
message using the session ID of the session to be resumed. The server then checks 
its session cache for a match. If a match is found, the server will send a server hello 
message with the same session ID value. The client sends a client hello message with 
the following parameters: 


— Client version: This is the version of the SSL protocol in which the client wishes to 
communicate during this session. This should be the most recent (highest-valued) 
version supported by the client. The value of this version will be 3.0. 
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— Random: This is a client-generated random structure with 28 bytes generated by 
a secure random number generator. 

— Session ID: This is the identity of a session when the client wishes to use this con- 
nection. A nonzero value indicates that the client wishes to update the parameters 
of an existing connection or create a new connection in this session. A zero value 
indicates that the client wishes to establish a new connection in a new session. 

— Cipher suites: This is a list of the cryptographic options supported by the client, 
with the client’s first preference first. The single cipher suite is an element of a 
list selected by the server from the list in ClientHello.cipher_suites. For a resumed 
session, this field is the value from the state of the session being resumed. 

— Compression method: This is a list of the compression methods supported by the 
client, sorted by client preference. If the session ID field is not empty, it must 
include the compression method from that session. 

e Server hello: The server will send the server hello message in response to a client hello 
message when it has found an acceptable set of algorithms. If it is unable to find such 
a match, it will respond with a handshake failure alert. The structure of this message 
consists of: server version, random, session ID, cipher suite and compression method. 


— Server version: This field will contain the lower-valued version suggested by the 
client in the client hello and the highest-valued version supported by the server. 
The value of this version is 3.0. 

— Random: This structure is generated by the server and must be different from 
ClientHello.random. 

— Session ID: This field represents the identity of the session corresponding to this 
connection. If the ClientHello.session_id is non-empty, the server will look in its 
session cache for a match. If a match is found and the server is willing to establish 
the new connection using the specified session state, the server will respond with 
the same value as was supplied by the client. This indicates a resumed session 
and dictates that the parties must proceed directly to the finished messages. 

— Cipher suite: This is the single cipher suite selected by the server from the list in 
ClientHello.cipher_suites. For a resumed session, this field is the value from the 
state of the session being resumed. 

— Compression method: This is the single compression algorithm selected by the 
server from the list in ClientHello.compression_methods. For a resumed sessions, 
this field is the value from the resumed session state. 


8.1.5.2 Phase 2: Server Authentication and Key Exchange 


Following the hello messages, the server begins this phase by sending its certificate if it 
needs to be authenticated. Additionally, a server key exchange message may be sent if it 
is required. If the server is authenticated, it may request a certificate from the client, if 
that is appropriate to the cipher suite selected. Then the server will send the server hello 
done message, indicating that the hello message phase of the handshake is complete. The 
server will then wait for a client response. If the server has sent a certificate request 
message, the client must send the certificate message. 
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Server certificate: If the server is to be authenticated, it must send a certificate imme- 
diately following the server hello message. The certificate type must be appropriate 
for the selected cipher suite’s key exchange algorithm, and is generally an X.509 v3 
certificate. It must contain a key which matches the key exchange method. The signing 
algorithm for the certificate must be the same as the algorithm for the certificate key. 
Server key exchange message: The server key exchange message is sent by the server 
only when it is required. This message is not used if the server certificate contains 
Diffie-Hellman parameters, or RSA key exchange is to be used for a signature- 
only RSA. 


— params: the server’s key exchange parameters. 

—  signed-params: for non-anonymous key exchange, a hash of the corresponding 
params value, with the signature appropriate to that hash applied. 

As usual, a signature is created by taking the hash of the message and encrypting it 

with the sender’s public key. Hence, the hash is defined as: 


md5-hash : MD5(ClientHello.random||ServerHello.random||serverParams) 
sha-hash : SHA(ClientHello.random||ServerHello.random||serverParams) 


enum {anonymous, rsa, dsa} SignatureAlgorithm; 


For a DSS signature, the hash is performed using the SHA-1 algorithm. In the case 
of an RSA signature, both an MD5 and an SHA-1 hash are calculated, and the con- 
catenation of the two hashes is encrypted with the server’s public key. 

Certificate request message: A non-anonymous server can optionally request a certifi- 
cate from the client, if appropriate for the selected cipher suite. This message includes 
two parameters, certificate type and certificate authorities. Its structure is as follows: 


enum{ 
rsa_sign(1), des sign(2), rsa_fixed_dh(3), 
dss_ fixed dh(4), 
rsa_ephemeral_dh(5), dss ephemeral _dh(6), 
fortezza_dms(20), (255) 
} ClientCertificateType; 
opaque DistinguishedName<1..2'6-1>; 
struct { 
ClientCertificateType certificate _types<1..2°-1>; 
DistinguishedName certificate_authorities<3. .2'6-1> 
} CertificateRequest; 


—  certificate_types: This field is a list of the types of certificates requested, sorted 
in order of the server’s preference. 

—  certificate_authorities: This is a list of the distinguished names of acceptable cer- 
tificate authorities. These distinguished names may specify a desired distinguished 
name for a root CA or for a subordinate CA; thus, this message can be used to 
describe both known roots and a desired authorization space. 
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Note that DistinguishedName is derived from X.509 and that it is a fatal handshake_ 
failure alert for an anonymous server to request client identification. 

e Server hello done message: This message is sent by the server to indicate the end 
of the server hello and associated messages. After sending this message, the server 
will wait for a client response. This message means that server has finished sending 
messages to support the key exchange, and the client can proceed with its phase of 
the key exchange. Upon receipt of the server hello done message, the client should 
verify that the server provided a valid certificate if required and check that the server 
hello parameters are acceptable. If all is satisfactory, the client sends one or more 
messages back to the server. 


8.1.5.3 Phase 3: Client Authentication and Key Exchange 


If the server has sent a certificate request message, the client must send the certificate 
message. The client key exchange message is then sent, and the content of that message 
will depend on the public key algorithm selected between the client hello and the server 
hello. If the client has sent a certificate with signing ability, a digitally signed certificate 
verify message is sent to explicitly verify the certificate. 


e Client certificate message: This is the first message the client can send after receiv- 
ing a server hello done message. This message is sent only when the server requests 
a certificate. If no suitable certificate is available, the client should send a certifi- 
cate message containing no certificates. If client authentication is required by the 
server for the handshake to continue, it may respond with a fatal handshake failure 
alert. The same message type and structure will be used for the client’s response to 
a certificate request message. Note that a client may send no certificates if it does 
not have an appropriate certificate to send in response to the server’s authentica- 
tion request. The client’s Diffie-Hellman certificates must match the server-specified 
Diffie-Hellman parameters. 


e Client key exchange message: This message is always sent by the client. It will imme- 
diately follow the client certificate message, if it is sent. Otherwise it will be the first 
message sent by the client after it receives the server hello done message. With this 
message, the premaster secret is set, either through direct transmission of the RSA- 
encrypted secret, or by transmission of Diffie-Hellman parameters which will allow 
each side to agree upon the same premaster secret. When the key exchange method 
is DH—RSA or DH-DSS, client certification has been requested, and the client was 
able to respond with a certificate which contained a Diffie-Hellman public key whose 
parameters matched those specified by the server in its certificate; this message will 
not contain any data. 


e Certificate verify message: This message is used to provide explicit verification of a 
client certificate. The message is only sent following any client certificate that has 
signing capability (i.e. all certificates except those containing fixed Diffie-Hellman 
parameters). When sent, it will immediately follow the client key exchange message. 
This message signs a hash code based on the preceding messages, and its structure is 
defined as follows: 
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struct{ 
Signature signature; 
} CertificateVerify; 
CertificateVerify.signature.md5_hash 
MD5(master_secret||pad2||MD5(handshake-message| | 
master_secret||pad1)) 
Certificate.signature.sha_hash 
SHA(master_secret| |pad2| |SHA(handshake-message| | 
master_secret||pad1)) 


where pad1 and pad2 are the values defined earlier for the MAC, handshake-messages 
refer to all Handshake Protocol messages sent or received starting at client-hello but 
not including this message, and master_secret is the calculated secret. If the user’s 
private key is DSS, then it is used to encrypt the SHA-1 hash. If the user’s private 
key is RSA, it is used to encrypt the concatenation of the MD5 and SHA-1 hashes. 


8.1.5.4 Phase 4: End of Secure Connection 


At this point, a change cipher spec message is sent by the client, and the client copies 
the pending CipherSpec into the current CipherSpec. The client then immediately sends 
the finished message under the new algorithms, keys and secrets. In response, the server 
will send its own change cipher spec message, transfer the pending CipherSpec to the 
current one, and then send its finished message under the new CipherSpec. At this point, 
the handshake is complete and the client and server may begin to exchange application 
layer data (see Figure 8.5). 


Change cipher spec messages: The client sends a change cipher spec message and 
copies the pending CipherSpec in the current CipherSpec. This message is immediately 
sent after the certificate verify message that is used to provide explicit verification of a 
client certificate. It is essential that a change cipher spec message is received between 
the other handshake messages and the finished message. It is a fatal error if a change 
cipher spec message is not preceded by a finished message at the appropriate point in 
the handshake. 

Finished message: This is always sent immediately after a change cipher spec message 
to verify that the key exchange and authentication processes were successful. The 
content of the finished message is the concatenation of two hash values: 


MD5(master_secret||pad2||MD5(handshake_messages||Sender| | 
master_secret||pad1)) 

SHA(master_secret| |pad2||SHA(handshake_messages||Sender| | 
master_secret||pad1)) 


where ‘Sender’ is a code that identifies that the sender is the client and ‘hand- 
shake_messages’ is code that identifies the data from all handshake messages up to 
but not including this message. 
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The finished message is first protected with just-negotiated algorithms, keys and 
secrets. Recipients of finished messages must verify that the contents are correct. Once 
a side has sent its finished message and received and validated the finished message 
from its peer, it may begin to send and receive application data over the connection. 
Application data treated as transparent data is carried by the Record Layer and is 
fragmented, compressed and encrypted based on the current connection state. 


8.2 Cryptographic Computations 


The key exchange, authentication, encryption and MAC algorithms are determined by 
the cipher suite selected by the server and revealed in the server hello message. The 
compression algorithm is negotiated in the hello messages, and the random values are 
exchanged in the hello messages. The creation of a shared master secret by means of the 
key exchange and the generation of cryptographic parameters from the master secrete are 
of interest to study as two further items. 


8.2.1. Computing the Master Secret 


For all key exchange methods, the same algorithm is used to convert the premaster secret 
into the master secret. In order to create the master secret, a premaster secret is first 
exchanged between two parties and then the master secret is calculated from it. The 
master secret is always exactly 48 bytes (384 bits) shared between the client and server. 
But the length of the premaster secret is not fixed and will vary depending on the key 
exchange method. There are two ways for the exchange of the premaster secret: 


e RSA: When RSA is used for server authentication and key exchange, a 48-byte pre- 
master secret is generated by the client, encrypted with the server’s public key and 
sent to the server. The server decrypts the ciphertext (of the premaster secret) using its 
private key to recover the premaseter secret. Both parties then convert the premaster 
secret into the master secret as specified below. 

e Diffie-Hellman: A conventional Diffie-Hellman computation is performed. Both 
client and server generate a Diffie-Hellman common key. This negotiated key is used 
as the premaster secret and is converted into the master secret, as specified below. 


The client and server then compute the master secret as follows: 


master_secret = MD5(pre_master_secret||SHA(‘A’ | | 
pre_master_secret||ClientHello.random| | 
ServerHello.random) ) | | 
MD5(pre_master_secret||SHA( ‘BB’ | | 
pre_master_secret||ClientHello.random]| | 
ServerHello.random) ) | | 
MD5(pre_master_secret||SHA( ‘CCC’ | | 
pre_master_secret||ClientHello.random]| | 
ServerHello.random) ) 
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Figure 8.6 Computation of the master secret. 


where ClientHello.random and ServerHello.random are the two nonce values exchanged 
in the initial hello messages. 
The generation of the master secret from the premaster secret is shown in Figure 8.6. 


8.2.2 Converting the Master Secret into Cryptographic 
Parameters 
CipherSpec specifies the bulk data encryption algorithm and a hash algorithm used for 


MAC computation, and defines cryptographic attributes such as the hash size. 
To generate the key material, the following is computed: 
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key_block = MD5(master_secret||SHA(‘A’||master_secret| | 
ServerHello.random| |ClientHello.random) ) | | 
MD5(master_secret||SHA(‘BB’||master_secret| | 
ServerHello.random| |ClientHello.random) ) | | 
MD5(master_secret||SHA(‘CCC’||master_secret| | 
ServerHello.random| |ClientHello.random) ) | |... 


until enough output has been generated. Note that the generation of the key block from 
the master secret uses the same format for generation of the master secret from the 
premaster secret. Figure 8.7 illustrates the steps for generation of the key block from the 
master secret. 
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Figure 8.7 Generation of key block. 
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8.3 TLS Protocol 


The TLSv1 protocol itself is based on the SSLv3 protocol specification as published by 
Netscape. Many of the algorithm-dependent data structures and rules are very close so 
that the differences between TLSv1 and SSLv3 are not dramatic. The current work on 
TLS is aimed at producing an initial version as an Internet standard. It is recommended 
that readers examine the comparative studies between the TLSv1 of RFC 2246 and SSLv3 
of Netscape. In this section, we will not repeat every detailed step of identical protocol 
contents, but only highlight the differences. 


8.3.1 HMAC Algorithm 


A Keyed-hashing Message Authentication Code (HMAC) is a secure digest of some data 
protected by a secret. Forging the HMAC is infeasible without knowledge of the MAC 
secret. HMAC can be used with a variety of different hash algorithms, namely MDS5 and 
SHA-1, denoting these as HMAC_MDS(secret, data) and HMAC_SHA-1| (secret, data). 

There are two differences between the SSLv3 and TLSMAC schemes. TLS makes use 
of the HMAC algorithm defined in RFC 2104. HMAC was fully discussed in Chapters 4 
and 7 and defined as: 


HMAC = H[(K @ opad)|| H[(K  ipad)||M]] 


where 


ipad = 00110110(0x36) repeated 64 times (512 bits) 
opad = 01011100(0Ox5c) repeated 64 times (512 bits) 
H = one-way hash function for TLS (either MD5 or SHA-1) 
M = message input to HMAC 
K = padded secret key equal to the block length of the hash code 
(512 bits for MD5 and SHA-1) 


The following explains the HMAC equation: 


1. Append zeros to the end of K to create a b-byte string (i.e. if K = 160 bits in length 
and b = 512 bits, then K will be appended with 352 zero bits or 44 zero bytes 0x00). 

2. XOR (bitwise exclusive-OR) K with ipad to produce the b-bit block computed in 

step 1. 

Append M to the b-byte string resulting from step 2. 

Apply H to the stream generated in step 3. 

5. XOR (bitwise exclusive-OR) K with opad to produce the b-byte string computed in 
step 1. 

6. Append the hash result H from step 4 to the b-byte string resulting from step 5. 

7. Apply H to the stream generated in step 6 and output the result. 


aS 
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Figure 8.8 Overall operation of HMAC computation using either MD5 or SHA-1 (message length 
computation based on Q;||M). 


Figure 8.8 illustrates the overall operation of HMAC-—MD5 or HMAC-SHA-1. 


Example 8.1 HMAC-SHA-1 computation using RFC method: 


Data : Ox 7104218 a3192e65 1cf7025d 8011bf79 4a19 
Key : Ox 31fa7062 c45113e3 2679fd13 53b71264 


= A B Cc D E 
IV 67452301 efcdab89 98badcfe 10325476 c3d2e1f0 
H[(K @ ipad)||M] 8efeef30  f64b360f 77fd8236 273f0784 613bbd4b 
H[(K @ opad)||H[(K ® 31db10b8 ed346850 dOf0b7dd SOfd71f4  2dacd24c 
ipad)||M]] 


HMAC-SHA-1 = 0x 31 db10b8 ed346850 dOf0b7dd SOfd71£4 2dacd24c 


The alternative operation for computation of either HMAC-—MD5 or HMAC-SHA-1 
is described in the following: 
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Figure 8.9 Alternative operation of HMAC computation using MD5 (message length computation 


is based on M only). 
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Append zeros to K to create a b-bit string K’, where b = 512 bits. 

XOR K’' (padding with zero) with ipad to produce the b-bit block. 

Apply the compression function f(I[V, K’® ipad) to produce (IV); = 128 bits. 
Compute the hash code A with (IV); and M;. 
Raise the hash value computed from step 4 to a b-bit string. 

XOR K’' (padded with zeros) with opad to produce the b-bit block. 

Apply the compression function f(IV, K’@ opad) to produce (IV), = 128 bits. 
Compute the HMAC with (IV), and the raised hash value resulting from step 5. 


Figure 8.9 illustrates the overall operation of HMAC-—MDS. 


Example 8.2 HMAC-MDS5 computation using alternative method: 


Data : Ox 2143f501 f014a713 c1059e23 7123fd68 
Key : 0x 31fa7062 c45113e3 2679fd13 53b71264 
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- A B C D 


IV 67452301 efcdab89 98badcfe 10325476 
f[(K @ ipad), 1V] = (IV); 13fbaf34 034879ab =: 35e73505 =: $26 a8d28 
H[M, (IV);] 90c6d9b0 Of281bc8 94d04b33 7£0£4265 
f[(K @ opad), [V] = (IV)o 5£8647d7 fa8e9afa bffa4989 3cd471d1 


A[A[M, IV)iI, TV)o] 2c47cd5b 68830268 74255059 45c7bef0 


HMAC-MDS = 0x 2c47cd5b 68830268 7d255059 45c7bef0 


For TLS, the MAC computation encompasses the fields indicated in the following 
expression: 


HMAC_hash(MAC_ write secret, seq_num||TLScompressed.type| | 
TLSCompressed.version||TLSCompressed. length] | 
TLSCompressed. fragment ) 


Note that the MAC calculation includes all of the fields covered by the SSLv3 com- 
putation, plus the field TLSCompressed.version, which is the version of the protocol 
being employed. 


8.3.2 Pseudo-random Function 


TLS utilizes a pseudo-random function (PRF) to expand secrets into blocks of data for 
the purposes of key generation or validation. The PRF takes relatively small values such 
as a secret, a seed and an identifying label as input and generates an output of arbitrary 
longer blocks of data. 

The data expansion function, P_hash(secret, data), uses a single hash function to expand 
a secret and seed into an arbitrary quantity of output. The data expansion function is 
defined as follows: 


P_hash(secret, seed) = HMAC_hash (secret, A(1)|| | | 
HMAC_hash (secret, A(2)||seed) || 
HMAC_hash (secret, A(3) || | | 


where A() is defined as: 


A(O) = seed 
A@) = HMAC_hash(secret, A(i-1)) and || indicates concatenation. 


Applying AQ), i= 0, 1, 2,..., to P_hash, the resulting sketch can be depicted as shown 
in Figure 8.10. As you can see, P_hash is iterated as many times as necessary to pro- 
duce the required quantity of data. Thus the data expansion function makes use of the 
HMAC algorithm with either MD5 or SHA-1 as the underlying hash function. As an 
example, consider SHA-1 whose value is 20 bytes (160 bits). If PLSHA-1 is used to cre- 
ate 64 bytes (512 bits) of data, it will have to be iterated four times up to A(4), creating 
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Figure 8.10 TLS data expansion mechanism using P_hash(secret,seed). 


20 x 4 = 80bytes (640 bits) of output data. Hence, the last 16 bytes (128 bits) of the 
final iteration A(4) must be discarded, leaving (80 — 16) = 64bytes of output data. On 
the other hand, MD5 produces 16 bytes (128 bits). In order to generate an 80-byte output, 
P_MD5S should exactly be iterated through A(5), while P_LSHA-1 will only iterate through 
A(4) as described above. In fact, alignment to a shared 64-byte output will be required 
to discard the last 16 bytes from both P_LSHA-1 and P_MDS5. 

TLS’s PRF is created by splitting the secret into two halves (S1 and S2) and using 
one half to generate data with PLMDS and the other half to generate data with P_SHA-1. 
These two results are then XORed to produce the output. S1 is taken from the first half of 
the secret and S2 from the second half. Their length is respectively created by rounding 
up the length of the overall secret divided by 2. Thus, if the original secret is an odd 
number of bytes long, the last bytes of S1 will be the same as the first byte of S2: 


L_S = length in bytes of secret 
L_S1 = L_S2 = ceil(L_S/2) 


298 INTERNET SECURITY 

The PREF is then defined as the result of mixing the two pseudo-random streams by 
XORing them together. The PRF is defined as: 
PRE (secret, label, seed) = PLMD5(S1, label|/seed) @ PLSHA — 1(S2, label||seed) 


The label is an ASCII string. Figure 8.11 illustrates the PRF generation scheme to 
expand secrets into blocks of data. 


Example 8.3 Refer to Figure 8.11. Suppose the following parameters are given: 


seed = Ox 80 af 12 5c 7e 36 f3 21 
label = rocky mountains = Ox 72 6f 63 6b 79 20 6d 6f 75 6e 74 61 69 6e 73 
secret = Ox 35 79 af 12 c4 


Then 


label||seed = Ox 72 6f 63 6b 79 20 6d 6f 75 6e 74 61 69 6e 73 80 af 12 5c Te 36 f3 21 
= A(0) 
S1 = Ox 35 79 af for PMD5, S2=0x af12c4 for PSHA-1 


Data expansion by P_LMDS: 
A(1) = HMAC_MDS(S1, A(0)) 
= d0 de 36 53 79 78 04 a0 21 b8 6f f8 29 60 d5 f7 


seed 


label 5) 














Si1—> _ P_MDS5 P_SHA-1 }¢— S82 





























PRF(secret, label, seed) 


S1: First half of the secret 
S2: Second half of the secret 


P_MDS: Data expansion function to expand a secret 
S1 and (seed| | secret) using MDS 
P_SHA-1: Data expansion function to expand a secret 
S2 and (seed| | secret) using SHA-1 


Figure 8.11 A pseudo-random function (PRF) generation scheme. 
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HMAC_MDS(S1, A(1)||A(O)) 

= 32 fd b3 70 eb 36 11 70 a4 3b 50 a9 fb ea 2a ec 
A(2) = HMAC_MDS(S1, A(1)) 

= 8c ce 5b 50 02 af 75 91 e7 20 cd 86 d9 3e 67 9d 
HMAC_MDS(S1, A(2)||A(O)) 

= If a8 4c af 5d el 20 01 ea bO 38 6a a5 76 f9 8e 
A(3) = HMAC_MDS(S1, A(2)) 

= 45 48 5d 00 4e 64 07 45 eb 2c 18 60 7c e6 fa If 
HMAC_MDS(S1, A(3)|| A()) 

= f0 23 29 d9 5e 89 4b 70 cc 45 f8 aa 1f 58 8e 55 
A(4) = HMAC_MDS(S1, A@G)) 

= 87 39 c6 d3 7a b f8 e3 29 79 3a ae 63 24 6a ff 
HMAC_MDS(S1, A(4)|| A()) 

= 2e Oc 27 26 dO b4 78 85 09 a2 69 Ic Ib 1b d7 8d 
A(5) = HMAC_MDS(S1, A(4)) 

= 3a 2c aa d8 b3 ec 2e 5d 40 Ic 39 bd 3e 48 la d9 
HMAC_MDS(S1, A(5)|| A()) 

= 92 f2 63 5d 88 3a dd bf 8d ec el cf Oc 5c 8f 4c 
where S1 = Ox 35 79 af = first half of the secret, and 
A(0) = labell||seed 


Thus, PLMD5 equals: 


32 fd b3 70 eb 36 11 70 a4 3b 50 a9 fb ea 2a 
lf a8 4c af 5d el 20 O1 ea bO 38 6a a5 76 f9 
fO 23 29 d9 5e 89 4b 70 cc 45 f8 aa If 58 8e 
2e Oc 27 26 dO b4 78 85 09 a2 69 Ic Ib Ib d7 
92 f2 63 5d 88 3a dd bf 8d ec el cf Oc Sc 8&f 


Data expansion by P_SHA-1: 


A(1) = HMAC_SHA1(S2, A(0)) 

= aa ea 46 1b a6 ad 43 34 51 £8 c6 ef 70 dd £4 60 ca b9 40 2f 
HMAC_SHAI(S2, A(1)|| A(O)) 

= dO 8a d5 07 e0 b8 30 78 70 d9 c8 bb dd ba f5 a3 dO 77 49 e8 
A(2) = HMAC_SHA1(S2, A(1)) 

= 33 fd 23 41 01 ce 06 f8 cO 2b b3 e6 54 21 Ic f4 6c 88 ab da 


299 


(80 bytes) 
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HMAC_SHAI(S2, A(2)|| A(O)) 

= 64 b5 cc 3f 79 31 5b 5d e6 e4 4f eb 98 a8 bf 3f 97 13 38 el 
A(3) = HMAC_SHAI1(S2, A(2)) 

= 86 If a3 a5 37 58 41 71 fl Of a5 £3 48 2e 5d 84 7c a8 b6 52 
HMAC_SHAI(S2, A(3)|| A(O)) 

= 03 26 11 02 ce 69 74 4a 21 f4 76 55 13 af 77 80 2d fb 2f 36 
A(4) = HMAC_SHAI1(S2, A(3)) 

= 9c 4d 01 3a 8c 48 54 42 68 07 4d fl f0 a9 78 c3 Of ab d8 b4 
HMAC_SHAI(S2, A(4)|| A(O)) 

= 48 56 04 b5 b4 Sf 9b d8 c7 2f 28 f6 Ye Id 8a c4 72 9a b9 32 
where S2 = Ox af 12 c4 = second half of the secret, and 
A(O) = label||seed 


Thus, PLSHA1 equals: 


dO 8a d5 07 e0 b& 30 78 70 d9 c8 bb dd ba f5 a3 
dO 77 49 e8 64 b5 cc 3f 79 31 Sb 5d e6 e4 4f eb 
98 a8 bf 3f 97 13 38 el 03 26 11 02 ce 69 74 4a 
21 f4 76 55 13 af 77 80 2d fb 2f 36 48 56 04 b5 
b4 Sf 9b d8 c7 2f 28 f6 9e Id 8a c4 72 9a b9 32 (80 bytes) 


Finally, PMD5 @ P_SHA — 1 equals: 


e2 77 66 77 Ob 8e 21 O08 d4 e2 98 12 26 50 df 4f 
cf df O05 47 39 54 ec 3e 93 81 63 37 43 92 b6 65 
68 8b 96 e6 c9 9a 73 91 cf 63 e9 aS dl 31 fa If 
Of f8 51 73 c3 Ib Of O5 24 59 46 2a 53 4d dB 38 
26 ad f8 85 4f 15 f5 49 13 fl 6b Ob Te c6 36 Te (80 bytes) 


8.3.3 Error Alerts 


The Alert Protocol is classified into the closure alert and the error alert. One of the content 
types supported by the TLS Record Layer is the alert type. Alert messages convey the 
severity of the message and a description of the alert. Alert messages with a fatal level 
result in the immediate termination of the connection. 

The client and the server must share knowledge that the connection is ending in order 
to avoid a truncation attack. Either party may initiate a close by sending a close_notify 
alert. This message notifies the recipient that the sender will not send any more messages 
on this connection. 

Error handling in the TLS Handshake Protocol is very simple. When an error is 
detected, the detecting party sends a message to the other party. Upon transmission or 
receipt of a fatal alert message, both parties immediately close the connection. 
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TLS supports all of the error alerts defined in SSLv3 with the exception of additional 
alert codes defined in TLS. The additional error alerts are described in the following: 


e decryption_failed: A TLS ciphertext is decrypted in an invalid way: either it was not an 
even multiple of the block length or its padding values, when checked, were incorrect. 
This message is always fatal. 

e record_overflow: A TLS record was received with a ciphertext whose length exceeds 
2'4 + 2048 bytes, or the ciphertext decrypted to a TLS compressed record with more 
than 2'+ + 1024 bytes. This message is always fatal. 

e unknown-ca: A valid certificate chain or partial chain was received, but the certificate 
was not accepted because the CA certificate could not be located or could not be 
matched with a known, trusted CA. This message is always fatal. 

e access_denied: A valid certificate was received, but when access control was applied, 
the sender decided not to proceed with the negotiation. This message is always fatal. 

e decode-error: A message could not be decoded because a field was out of its specified 
range or the length of the message was incorrect. This message was incorrect. It is 
always fatal. 

e decrypt_error: A handshake cryptographic operation failed, including being unable to 
verify a signature, decrypt a key exchange or validate a finished message. 

e export_restriction: A negotiation not in compliance with export restrictions was 
detected; for example, attempting to transfer a 1024-bit ephemeral RSA key for the 
RSA_EXPORT handshake method. This message is always fatal. 

e protocol_version: The protocol version the client has attempted to negotiate is recog- 
nised but not supported due to the fact that old protocol versions might be avoided 
for security reasons. This message is always fatal. 

e insufficient_security: Returned instead of hanshake_failure when a negotiation has 
failed specifically because the server requires ciphers more secure than those supported 
by the client. This message is always fatal. 

e internal_error: An internal error unrelated to the peer or the correctness of the protocol, 
such as a memory allocation failure, makes it impossible to continue. This message 
is always fatal. 

e user_canceled: This handshake is being cancelled for some reason unrelated to a pro- 
tocol failure. If the user cancels an operation after the handshake is complete, just 
closing the connection by sending a close_notify is more appropriate. This alert should 
be followed by a close_notify. This message is generally a warning. 

e no-_renegotiation: This is sent by the client in response to a hello request or by the 
server in response to a client hello after initial handshaking. Either of these messages 
would normally lead to renegotiation, but this alert indicates that the sender is not 
able to renegotiate. This message is always a warning. 


For all errors where an alert level is not explicitly specified, the sending party may 
determine at its discretion whether this is a fatal error or not; if an alert with a level of 
warning is received, the receiving party may decide at its discretion whether to treat this 
as a fatal error or not. However, all messages which are transmitted with a level of fatal 
must be treated as fatal messages. 
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8.3.4 Certificate Verify Message 


Recall that the hash computations for SSLv3 are included with the master secret, the 
handshake message and pads. In the TLS certificate verify message, the MDS and SHA-1 
hashes are calculated only over handshake messages as shown below: 


CertificateVerify.signature.md5_hash 
MD5 (handshake_message) 
CertificateVerify.signature.sha_hash 
SHA(handshake_message) 


Here handshake messages refer to all handshake messages sent or received starting at 
client hello up to, but not including, this message, including the type and length fields of 
the handshake messages. 


8.3.5 Finished Message 


A finished message is always sent immediately after a change cipher spec message to 
verify that the key exchange and authentication processes were successful. It is essential 
that a change cipher spec message be received between the other handshake messages 
and the finished message. As with the finished message in SSLV3, the finished message in 
TLS is a hash based on the shared master_secret, the previous handshake messages, and 
a label that identifies client and server. However, the TLS computation for verify_data is 
somewhat different from that of the SSL calculation as shown below: 


PRF(master_secret, finished label, MD5(handshake_message) | | 
SHA-1(handshake_message) ) 


where 


e The finished_label indicates either the string ‘client finished’ sent by the client or the 
string ‘server finished’ sent by the server, respectively. 

e The handshake_message includes all handshake messages starting at client hello up 
to, but not including, this finished message. This is only visible at the handshake layer 
and does not include record layer headers. In fact, this is the concatenation of all 
the handshake structures exchanged thus far. This may be different from handshake 
messages for SSL because it would include the certificate verify message. Also, the 
handshake_message for the finished message sent by the client will be different from 
that for the finished message sent by the server. 


Note that change cipher spec messages, alters and any other record types are not 
handshake messages and are not included in the hash computations. 


8.3.6 Cryptographic Computations (for TLS) 


In order to begin connection protection, the TLS Record Protocol requires specifica- 
tion of a suite of algorithms, a master secret, and the client and server random values. 
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The authentication, encryption and MAC algorithms are determined by the cipher_suite 
selected by the server and revealed in the server hello message. The compression algo- 
rithm is negotiated in the hello messages, and the random values are exchanged in the 
hello messages. 

All that remains is to compute the master secret and the key block. The premaster-secret 
for TLS is calculated in the same way as in SSLv3. The presmater_secret should be deleted 
from memory once the master_secret has been computed. As in SSLv3, the master_secret 
in TLS in calculated as a hash function of the premaster_secret and two hello random 
numbers. The TLS master_secret computation is different from that of SSLv3 and is 
defined as follows: 


master_secret = PRF(premaster_secret, ‘‘master secret’’, 
ClientHello.random| |ServerHello. random) 


The master_secret is always exactly 48 bytes (384 bits) in length. The length of the 
premaster-_secret will vary depending on key exchange method: 


e RSA: When RSA is used for server authentication and key exchange, a 48-byte pre- 
master_secret is generated by the client, encrypted with the server’s public key, and 
sent to the server. The server uses its private key to decrypt the premaster_secret. Both 
parties then convert the premaster_secret into the master_secret, as specified above. 

e Diffie—Hellman: A conventional Diffie-Hellman computation is performed. The nego- 
tiated key Z is used as the premaster_secret, and is converted into the master_secret, 
as specified above. 


The computation of the key block parameters (MAC secret keys, session encryption 
keys and IVs) is defined as follows: 


key_block = PRF(master_secret, ‘‘key expansion’’, 
SecurityParameters.server_random| | 
SecurityParameters.client_random) 


until enough output has been generated. As with SSLv3, key_block is a function of the 
master_secret and the client and server random numbers, but for TLS the actual algorithm 
is different. 

On leaving this chapter, it is recommended that readers search for and find any other 
small differences between SSL and TLS. 


9 


Electronic Mail Security: 
PGP, S/MIME 


Pretty Good Privacy (PGP) was invented by Philip Zimmermann who released version 
1.0 in 1991. Subsequent versions 2.6.x and 5.x (or 3.0) of PGP have been implemented 
by an all-volunteer collaboration under the design guidance of Zimmermann. PGP is 
widely used in the individual and commercial versions that run on a variety of platforms 
throughout the computer community. PGP uses a combination of symmetric secret-key 
and asymmetric public-key encryption to provide security services for electronic mail 
and data files. It also provides data integrity services for messages and data files by 
using digital signature, encryption, compression (zip) and radix-64 conversion (ASCII 
Armor). With the explosively growing reliance on e-mail and file storage, authentication 
and confidentiality services have become increasing demands. 

MIME is an extension to the RFC 2822 framework which defines a format for text 
messages being sent using e-mail. MIME is actually intended to address some of the 
problems and limitations of the use of SMTP. Secure/Multipurpose Internet Mail Exten- 
sion (S/MIME) is a security enhancement to the MIME Internet e-mail format standard, 
based on technology from RSA Data Security. 

Although both PGP and S/MIME are on an IETF standards track, it appears likely that 
PGP will remain the choice for personnel e-mail security for many users, while S/MIME 
will emerge as the industry standard for commercial and organisational use. Two schemes 
of PGP and S/MIME are discussed in this chapter. 


9.1 PGP 


Before looking at the operation of PGP in detail, it is convenient to confirm the notation. 
In the forthcoming analyses for security and data integrity services, the following symbols 
are generally used: 
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K, =session key H = hash function 

K P, = public key of user A K P, = public key of user B 
KS, = private key of user A K Spy = private key of user B 
E = conventional encryption D = conventional decryption 
Ep, = public-key encryption Dy = public-key decryption 

Z = compression using zip algorithm Z~! = decompression 

|| = concatenation 


9.1.1 Confidentiality via Encryption 


PGP provides confidentiality by encrypting messages to be transmitted or data files to be 
stored locally using a conventional encryption algorithm such as IDEA, 3DES or CAST- 
128. In PGP, each symmetric key, known as a session key, is used only once. A new 
session key is generated as a random 128-bit number for each message. Since it is used 
only once, the session key is bound to the message and transmitted with it. To protect 
the key, it is encrypted with the receiver’s public key. Figure 9.1 illustrates the sequence, 
which is described as follows: 


e The sender creates a message. 

e The sending PGP generates a random 128-bit number to be used as a session key for 
this message only. 

e The session key is encrypted with RSA, using the recipient’s public key. 

e The sending PGP encrypts the message, using CAST-128 or IDEA or 3DES, with the 
session key. Note that the message is also usually compressed. 

e The receiving PGP uses RSA with its private key to decrypt and recover the ses- 
sion key. 

e The receiving PGP decrypts the message using the session key. If the message was 
compressed, it will be decompressed. 


Sender A Receiver B 
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Figure 9.1 PGP confidentiality computation scheme with compression/decompression Algorithms. 


ELECTRONIC MAIL SECURITY: PGP, S/MIME 307 


Instead of using RSA for key encryption, PGP may use a variant of Diffie-Hellman 
(known as ElGamal) that does provide encryption/decryption. In order for the encryption 
time to reduce, the combination of conventional and public-key encryption is used in 
preference to simply using RSA or ElGamal to encrypt the message directly. In fact, 
CAST-128 and other conventional algorithms are substantially faster than RSA or ElGa- 
mal. Since the recipient is able to recover the session key that is bound to the message, 
the use of the public-key algorithms solves the session key exchange problem. Finally, 
to the extent that the entire scheme is secure, PGP should provide the user with a range 
of key size options from 768 to 3072 bits. 

Both digital signature and confidentiality services may be applied to the same message. 
First, a signature is generated from the message and attached to the message. Then the 
message plus signature are encrypted using a symmetric session key. Finally, the session 
key is encrypted using public-key encryption and prefixed to the encrypted block. 


9.1.2 Authentication via Digital Signature 


The digital signature uses a hash code of the message digest algorithm, and a public-key 
signature algorithm. Figure 9.2 illustrates the digital signature service provided by PGP. 
The sequence is as follows: 


e The sender creates a message. 

e SHA-1 is used to generate a 160-bit hash code of the message. 

e The hash code is encrypted with RSA using the sender’s private key and a digital 
signature is produced. 

e The binary signature is attached to the message. 

e The receiver uses RSA with the sender’s public key to decrypt and recover the 
hash code. 

e The receiver generates a new hash code for the received message and compares it 
with the decrypted hash code. If the two match, the message is accepted as authentic. 


The combination of SHA-1 and RSA provides an effective digital signature scheme. 
As an alternative, signatures can be generated using DSS/SHA-1. The National Institute 
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Figure 9.2 PGP authentication computation scheme using compression algorithm. 
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of Standards and Technology (NIST) has published FIPS PUB 186, known as the Digital 
Signature Standard (DSS). The DSS uses an algorithm that is designed to provide only 
the digital signature function. Although DSS is a public-key technique, it cannot be used 
for encryption or key exchange. The DSS approach for generating digital signatures was 
fully discussed in Chapter 5. The DSS makes use of the secure hash algorithm (SHA-1) 
described in Chapter 4 and presents a new digital signature algorithm (DSA). 


9.1.3. Compression 


As a default, PGP compresses the message after applying the signature but before encryp- 
tion. The placement of Z for compression and Z~! for decompression is shown in 
Figures 9.1 and 9.2. This compression algorithm has the benefit of saving space both 
for e-mail transmission and for file storage. However, PGP’s compression technique will 
present a difficulty. 

Referring to Figure 9.1, message encryption is applied after compression to strengthen 
cryptographic security. In reality, cryptanalysis will be more difficult because the com- 
pressed message has less redundancy than the original message. 

Referring to Figure 9.2, signing an uncompressed original message is preferable 
because the uncompressed message together with the signature are directly used for future 
verification. On the other hand, for a compressed message, one may consider two cases, 
either to store a compressed message for later verification or to recompress the message 
when verification is required. Even if a recompressed message were recovered, PGP’s 
compression algorithm would present a difficulty due to the fact that different trade-offs 
in running speed versus compression ratio produce different compressed forms. 

PGP makes use of a compression package called ZIP which is functionally equivalent 
to PKZIP developed by PKWARE, Inc. The zip algorithm is perhaps the most commonly 
used cross-platform compression technique. 

Two main compression schemes, named after Abraham Lempel and Jakob Ziv, were 
first proposed by them in 1977 and 1978, respectively. These two schemes for text com- 
pression (generally referred to as lossless compression) are broadly used because they are 
easy to implement and also fast. 

In 1982 James Storer and Thomas Szymanski presented their scheme, LZSS, based 
on the work of Lempel and Ziv. In LZSS, the compressor maintains a window of size 
N bytes and a lookahead buffer. Sliding-window-based schemes can be simplified by 
numbering the input text characters mod N, in effect creating a circular buffer. Variants 
of sliding-window schemes can be applied for additional compression to the output of the 
LZSS compressor, which include a simple variable-length code (LZB), dynamic Huffman 
coding (LZH) and Shannon—Fano coding (ZIP 1.x). All of them result in a certain degree 
of improvement over the basic scheme, especially when the data is rather random and the 
LZSS compressor has little effect. 

Recently an algorithm was developed which combines the idea behind LZ77 and LZ78 
to produce a hybrid called LZFG. LZFG uses the standard sliding window, but stores the 
data in a modified tree data structure and produces as output the position of the text in the 
tree. Since LZFG only inserts complete phrases into the dictionary, it should run faster 
than other LZ77-based compressors. 
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Huffman compression is a statistical data compression technique which reduces the 
average code length used to represent the symbols of an alphabet. Huffman code is an 
example of a code which is optimal when all symbols probabilities are integral powers 
of 1/2. A technique related to Huffman coding is Shannon—Fano coding. This coding 
divides the set of symbols into two equal or almost equal subsets based on the probability 
of occurrence of characters in each subset. The first subset is assigned a binary 0, the 
second a binary 1. Huffman encoding always generates optimal codes, but Shannon—Fano 
sometimes uses a few more bits. 

Decompression of LZ77-compressed text is simple and fast. Whenever a (position, 
length) pair is encountered, one goes to that position in that window and copies length 
bytes to the output. 


9.1.4 Radix-64 Conversion 


When PGP is used, usually part of the block to be transmitted is encrypted. If only 
the signature service is used, then the message digest is encrypted (with the sender’s 
private key). If the confidentiality service is used, the message plus signature (if present) 
are encrypted (with a one-time symmetric key). Thus, part or all of the resulting block 
consists of a stream of arbitrary 8-bit octets. However, many electronic mail systems only 
permit the use of blocks consisting of ASCII text. To accommodate this restriction, PGP 
provides the service of converting the raw 8-bit binary octets to a stream of printable 
7-bit ASCII characters, called radix-64 encoding or ASCII Armor. Therefore, to transport 
PGP’s raw binary octets through unreliable channels, a printable encoding of these binary 
octets is needed. 

The scheme used for this purpose is radix-64 conversion. Each group of three octets 
of binary data is mapped into four ASCII characters. This format also appends a CRC to 
detect transmission errors. This radix-64 conversion is a wrapper around the binary PGP 
messages, and is used to protect the binary messages during transmission over non-binary 
channels, such as Internet e-mail. 

Table 9.1 shows the mapping of 6-bit input values to characters. The character set 
consists of the upper- and lower-case letters, the digits O—9, and the characters ‘+’ and 
‘/?. The ‘=’ character is used as the padding character. The hyphen ‘-’ character is 
not used. 

Thus, a PGP text file resulting from ASCII characters will be immune to the modifi- 
cations inflicted by mail systems. It is possible to use PGP to convert any arbitrary file to 
ASCII Armor. When this is done, PGP tries to compress the data before it is converted 
to Radix-64. 


Example 9.1 Consider the mapping of a 24-bit input (a block of three octets) into a 
four-character output consisting of the 8-bit set in the 32-bit block. 


Suppose the 24-bit raw text is: 
10110010 01100011 00101001 


The hexadecimal representation of this text sequence is b2 63 29. 
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Table 9.1 Radix-64 encoding 


6-bit Character 6-bit Character 6-bit Character 6-bit Character 


value encoding value encoding value encoding value encoding 

0 A 16 Q 32 g 48 Ww 
1 B 17 R 33 h 49 x 
2 C 18 S 34 i 50 y 
3 D 19 T 35 j 51 Z 
4 E 20 U 36 k 52 0 
5 F 21 Vv 37 1 53 1 
6 G 22 Ww 38 m 54 2 
7 H 23 x 39 n 55 3 
8 I 24 Y 40 oO 56 4 
9 J 25 Z 41 p 57 5 
10 K 26 a 42 q 58 6 
11 L 27 b 43 r 59 el 
12 M 28 c 44 s 60 8 
13 N 29 d 45 t 61 9 
14 O 30 e 46 u 62 + 
15 P 31 f 47 Vv 63 / 
(pad) = 


Arranging this input sequence in blocks of 6 bits yields: 
101100 100110 001100 101001 


The extracted 6-bit decimal values are 44, 38, 12, 41. 
Referring to Table 9.1, the radix-64 encoding of these decimal values produces the fol- 
lowing characters: 


smMp 


If these characters are stored in 8-bit ASCII format with zero parity, we have them in 
hexadecimal as follows: 


73 6d 4d 70 
In binary representation, this becomes: 


01110110 01101101 01001101 01110000 


9.1.4.1 ASCII Armor Format 


When PGP encodes data into ASCII Armor, it puts specific headers around the data, so 
PGP can construct the data later. PGP informs the user about what kind of data is encoded 
in ASCII Armor through the use of the headers. 

Concatenating the following data creates ASCII Armor: an Armor head line, Armor 
headers, a blank line, ASCII-Armored data, Armor checksum and Armor tail. Specifically, 
an explanation for each item is as follows: 
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An Armor head line: This consists of the appropriate header line text surrounded by 
five dashes (‘-’, Ox2D) on either side of the header line text. The header line text is 
chosen based upon the type of data that is being encoded in Armor, and how it is 
being encoded. Header line texts include the following strings: 


— BEGIN PGP MESSAGE - used for signed, encrypted or compressed files. 

— BEGIN PGP PUBLIC KEY BLOCK - used for armouring public keys. 

— BEGIN PGP PRIVATE KEY BLOCK - used for armouring private keys. 

— BEGIN PGP MESSAGE, PART X/Y — used for multipart messages, where the 
armour is divided amongst Y parts, and this is the Xth part out of Y. 

— BEGIN PGP MESSAGE, PART X — used for multipart messages, where this is 
the Xth part of an unspecified number of parts; requires the MESSAGE-ID Armor 
header to be used. 

— BEGIN PGP SIGNATURE - used for detached signatures, PGP/MIME signatures 
and natures following clear-signed messages. Note that PGP 2.xs BEGIN PGP 
MESSAGE is used for detached signatures. 





Armor headers: There are pairs of strings that can give the user or the receiving 
PGP implementation some information about how to decode or use the message. The 
Armor headers are a part of the armour, not a part of the message, and hence are not 
protected by any signatures applied to the message. The format of an Armor header 
is that of a (key, value) pair. A colon (‘:’ 0x38) and a single space (0x20) separate 
the key and value. PGP should consider improperly formatted Armor headers to be 
corruptions of ASCII Armor. Unknown keys should be reported to the user, but PGP 
should continue to process the message. 
Currently defined Armor header keys include: 


— Version: This states the PGP version used to encode the message. 

— Comment: This is a user-defined comment. 

—  MessagelID: This defines a 32-character string of printable characters. The string 
must be the same for all parts of a multipart message that uses the ‘PART X’ 
Armor header. MessageID string should be unique enough that the recipient of the 
mail can associate all the parts of a message with each other. A good checksum 
or cryptographic hash function is sufficient. 

— Hash: This is a comma-separated list of hash algorithms used in the message. 
This is used only in clear-signed messages. 

— Charset: This is a description of the character set that the plaintext is in. PGP 
defines text to be in UTF-8 by default. An implementation will get the best results 
by translating into and out of UTF-8 (see RFC 2279). However, there are many 
instance where this is easier said than done. Also, there are communities of users 
who have no need for UTF-8 because they are all satisfied with a character set 
like ISO Latin-5 or a Japanese one. In such instances, an implementation may 
override the UTF-8 default by using this header key. 


A blank line: This indicates zero length or contains only white space. 
ASCH-Armoured data: An arbitrary file can be converted to ASCII-Armoured data by 
using Table 9.1. 
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Armor checksum: This is a 24-bit CRC converted to four characters of radix-64 encod- 
ing by the same MIME base 64 transformation, preceded by an equals sign (=). The 
CRC is computed by using the generator 0x864cfb and an initialisation of 0xb704ce. 
The accumulation is done on the data before it is converted to radix-64, rather than 
on the converted data. The checksum with its leading equals sign may appear on the 
first line after the base 64 encoded data. 

Armor tail: The Armor tail line is composed in the same manner as the Armor header 
line, except the string ‘BEGIN’ is replaced by the string ‘END’. 


9.1.4.2 Encoding Binary in Radix-64 


The encoding process represents three 8-bit input groups as output strings of four encoded 
characters. These 24 bits are then treated as four concatenated 6-bit groups, each of which 
is translated into a single character in the radix-64 alphabet. Each 6-bit group is used as 
an index. The character referenced by the index is placed in the output string. 


Special processing is performed if fewer than 24 bits are available at the end of the 


data being encoded. There are three possibilities: 


1. 


The last data group has 24 bits (three octets). No special processing is needed. 

The last data group has 16 bits (two octets). The first two 6-bit groups are processed 
as above. The third (incomplete) data group has two zero-value bits added to it, and 
is processed as above. A pad character (=) is added to the output. 

The last data group has 8 bits (one octet). The first 6-bit group is processed as above. 
The second (incomplete) data group has four zero-value bits added to it, and is 
processed as above. Two pad characters (=) are added to the output. 


Radix-64 printable encoding of binary data is shown in Figure 9.3. 
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Figure 9.3. Radix-64 printable encoding of binary data. 
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Example 9.2 Consider the encoding process from 8-bit input groups to the output 
character string in the radix-64 alphabet. 


1. Input raw text: Ox 15 dO 2f 9e b7 4c 


8-bit octets: 00010101 11010000 00101111 10011110 10110111 01001100 
6-bit index: 000101 011101 000000 101111 100111 101011 011101 001100 
Decimal: 5 29 0 47 39 43 29 12 

Output character: FdAvnordM 

(radix-64 encoding) 

ASCII format (Ox): 46 64 41 76 6e 72 64 4d 

Binary: 01000110 01100100 01000001 01110110 


01101110 01110010 01100100 01001101 
2. Input raw text: Ox 15 dO 2f 9e b7 


8-bit octets: 00010101 11010000 00101111 10011110 10110111 
6-bit index: 000101 011101 000000 101111 100111 101011 011100 
Pad with 00 (=) 
Decimal: 5 29 0 47 39 43 28 
Output character: FdAvonre=z 
3. Input raw text: Ox 15 dO 2f 9e 

8-bit octets: 00010101 11010000 00101111 10011110 

6-bit index: 000101 011101 000000 101111 100111 100000 
Pad with 0000 (==) 

Decimal: 5 29 0 47 39 32 

Output character: FdAvng== 


9.1.5 Packet Headers 


A PGP message is constructed from a number of packets. A packet is a chunk of data 
which has a tag specifying its meaning. Each packet consists of a packet header of variable 
length, followed by the packet body. 

The first octet of the packet header is called the packet tag as shown in Figure 9.4. The 
MSB is ‘bit 7’ (the leftmost bit) whose mask is 0x80 (10000000) in hexadecimal. PGP 
2.6.x only uses old format packets. Hence, software that interoperates with PGP 2.6.x 
must only use old format packets. These packets have 4 bits of content tags, but new 
format packets have 6 bits of content tags. 


9.1.5.1 Packet Tags 


The packet tag denotes what type of packet the body holds. The defined tags (in deci- 
mal) are: 


O0—Reserved 
1—Session key packet encrypted by public key 
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MSB Packet tag Pi Packet length ——4 


7 6 5 4 | 3 2 1 0 
Content tag Length 
© (4 bits) type = 
Content tag 
@) (6 bits) 


a) Old format packets: content tag (bits 5, 4, 3, 2); length type (bits 1,0) 











Q) New format packets: content tag (bits 5, 4, 3, 2, 1, 0) 


Figure 9.4 Packet header. 


2—Signature packet 

3—Session key packet encrypted by symmetric key 
4—One-pass signature packet 
5—Secret-key packet 

6—Public-key packet 

7—Secret-subkey packet 

8—Compressed data packet 
9—Symmetrically encrypted data packet 
10—Marker packet 

11-Literal data packet 

12—Trust packet 

13—User ID packet 

14—Public subkey packet 

60 ~ 63—Private or experimental values 


9.1.5.2 Old-Format Packet Lengths 


The meaning of the length type in old-format packets is: 


0-The packet has a one-octet length. The header is two octets long. 

1—The packet has a two-octet length. The header is three octets long. 

2—The packet has a four-octet length. The header is five octets long. 

3-The packet is of indeterminate length. An implementation should not use indeterminate 
length packets except where the end of data will be clear from the context. It is better 
to use a new-format header described below. 


9.1.5.3 New-Format Packet Lengths 


New-format packets have four possible ways of encoding length: 
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e One-octet lengths: A one-octet body length header encodes packet lengths from 0 to 
191 octets. This type of length header is recognised because the one-octet value is 
less that 192. The body length is equal to: 


bodyLen = I|st_octet 


e Two-octet lengths: A two-octet body length header encodes a length from 192 to 8383 
octets. It is recognised because its first octet is in the range 192 to 223. The body 
length is equal to: 


bodyLen = ((1st_octet — 192) « 8) + (2nd_octet) + 192 


e Five-octet lengths: A five-octet body length header encodes packet lengths of up to 
4294 967 295 (Oxffffffff) octets in length. This header consists of a single octet holding 
the value 255, followed by a four-octet scalar. The body length is equal to: 


bodyLen = (2nd_octet « 24)|(3rd_octet « 16)|(4th_octet < 8)|5th_octet 


e Partial body lengths: A partial body length header is one octet long and encodes 
the length of only part of the data packet. This length is a power of 2, from | to 
1073 741 824 (2 to the 30th power). It is recognised by its one-octet value that is 
greater than or equal to 224, and less than 255. The partial body length is equal to: 


partialBodyLen = | « (Ist_octet & OxIf) 


Each partial body length header is followed by a portion of the packet body data. The 
header specifies this portion’s length. Another length header (of one of the three types: 
one octet, two octet or partial) follows that portion. The last length header in the packet 
must not be a partial body length header. The latter headers may only be used for the 
non-final parts of the packet. 


Example 9.3 Consider a packet with length 100. Compute its length encoded in one octet. 
Now: 


100 (decimal) = 2° + 2° + 27 = 01100100(binary) = 0x64 (hex) 


Thus, a packet with length 100 may have its length encoded in one octet: 0x64. This 
header is followed by 100 octets of data. Similarly, a packet with length 1723 may have 
its length encoded in two octets: Oxc5, Oxfb. This header is followed by the 1723 octets 
of data. A packet with length 100000 may have its length encoded in five octets: Oxff, 
0x00, 0x01, 0x86, Oxa0. 


9.1.6 PGP Packet Structure 


A PGP file consists of a message packet, a signature packet and a session key packet. 


9.1.6.1 Message Packet 


This packet includes the actual data to be transmitted or stored as well as a header that 
includes control information generated by PGP such as a filename and a timestamp. A 
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timestamp specifies the time of creation. The message component consists of a single 
literal data packet. 


9.1.6.2 Signature Packet (Tag 2) 


This packet describes a binding between some public key and some data. The most 
common signatures are a signature of a file or a block of text, and a signature that is a 
certification of a user ID. 

Two versions of signature packets are defined. PGP 2.6.x only accepts version 3 
signature. Version 3 provides basic signature information, while version 4 provides an 
expandable format with subpackets that can specify more information about the signa- 
ture. It is reasonable to create a v3 signature if an implementation is creating an encrypted 
and signed message that is encrypted with a v3 key. 

At first, version 3 for basic signature information will be presented in the following. 
The signature packet is the signature of the message component, formed using a hash code 
of the message component and sender a’s public key. The signature component consists 
of single signature packet. 

The signature includes the following components: 


Timestamp: This is the time at which the signature was created. 

Message digest (or hash code): A hash code represents the 160-bit SHA-1 digest, 
encrypted with sender a’s private key. The hash code is calculated over the signa- 
ture timestamp concatenated with the data portion of the message component. The 
inclusion of the signature timestamp in the digest protects against replay attacks. The 
exclusion of the filename and timestamp portion of the message component ensures 
that detached signatures are exactly the same as attached signatures prefixed to the 
message. Detached signatures are calculated on a separate file that has none of the 
message component header fields. 


If the default option of compression is chosen, then the block consisting of the literal 
data packet and the signature packet is compressed to form a compressed data packet: 


e Leading two octets of hash code: These enable the recipient to determine if the correct 
public key was used to decrypt the hash code for authentication, by comparing the 
plaintext copy of the first two octets with the first two octets of the decrypted digest. 
Two octets also serve as a 16-bit frame-check sequence for the message. 

e Key ID of sender’s public key: This identifies the public key that should be used to 
decrypt the hash code and hence identifies the private key that was used to encrypt 
the hash code. 


The message component and signature component (optional) may be compressed using 
ZIP and may be encrypted using a session key. 

There are a number of possible meanings of a signature, which are specified in 
signature-type octets as shown below: 


0x00: Signature of a binary document 
Ox01: Signature of a canonical text document 
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0x02: Stand-alone signature 
0x10: Generic certification of a user ID and public-key packet 
(All PGP key signatures are of this type of certification.) 
Ox11: Personal certification of a user ID and public-key packet 
(The issuer has not carried out any verification of the claim.) 
0x12: Casual certification of a user ID and public-key packet 
(The issuer has carried out some casual verification of the identity claim.) 
0x13: Positive certification of a user ID and public-key packet 
(The issuer has carried out substantial verification of the identity claim.) 
0x18: Subkey binding signature 
(This signature is a statement by the top-level signing key indicating that it owns 
the subkey.) 
Ox1f: Signature directly on a key 
(This signature is calculated directly on a key. It binds the information in the signature 
subpackets to the key.) 
0x20: Key revocation signature 
(This signature is calculated directly when the key is revoked. A revoked key is not 
to be used.) 
0x28: Subkey revocation signature 
(This signature is calculated directly when the subkey is revoked. A revoked subkey 
is not to be used.) 
0x30: Certification revocation signature 
(This signature revokes an earlier user ID certification signature. It should be issued 
by the same key that issued the revoked signature or an authorised revocation key.) 
0x40: Timestamp signature 
(This signature is only meaningful for the timestamp contained in it.) 


The contents of the signature packets of version 3 (V3) and version 4 (V4) are illustrated 
in Table 9.2. 

The signature calculation for version 4 signature is based on a hash of the signed data. 
The data being signed is hashed, and then the signature data from the version number to 
the hashed subpacket data is hashed. The resulting hash value is what is signed. The left 
16 bits of the hash are included in the signature packet to provide a quick test to reject 
some invalid signatures. 


9.1.6.3 Session Key Packets (Tag 1) 


This component includes the session key and the identifier of the receiver’s public key 
that was used by the sender to encrypt the session key. A public-key-encrypted session 
key packet, Ex p,(K;), holds the session key used to encrypt a message. The symmetrically 
encrypted data packets are preceded by one public-key-encrypted session key packet for 
each PGP 5.x key to which the message is encrypted. The message is encrypted with the 
session key, and the session key is itself encrypted and stored in the encrypted session 
key packet. The recipient of the message finds a session key that is encrypted to its public 
key, decrypts the session key, and then uses the session key to decrypt the message. 
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Table 9.2 Signature packet format of version 3 and version 4 


Content Length in octets 
V3 v4 
Version number: V3(3), V4(4) 1 1 
Signature type 1 1 
Creation time 4 
Signer’s key ID 8 
Public-key algorithm 1 1 
Hash algorithm 1 1 
Field holding left 16 bits of 2 2. 
signed hash value 
One or more MPIs comprising Algorithm specific* Algorithm specific 
the signature 
Scalar octet count for hashed 2, 
subpacket data 
Hashed subpacket data Zero or more 
subpackets 
Scalar octet count for all of the 2 
unhashed subpackets 
Unhashed subpacket data Zero or more 
subpackets 


*Algorithm-specific fields for RSA signature: MPI of RSA signature value m¢; algorithm- 
specific fields for DSA signature: MPI of DSA value r, MPI of DSA value s. (MPI = 
Multiprecision Integer) 


The body of this session key component consists of: 


A one-octet version number which is 3. 

An eight-octet key ID of the public key that the session key is encrypted to. 

A one-octet number giving the public key algorithm used. 

A string of octets that is the encrypted session key. This string’s contents are dependent 
on the public-key algorithm used: 


—  Algorithm-specific fields for RSA encryption: multiprecision integer (MPI) of 
RSA encrypted value m°-mod n. 

—  Algorithm-specific fields for ElGamal encryption: MPI of ElGamal value g* mod 
p; MIP of ElGamal value my* mod p. The value ‘m’ is derived from the ses- 
sion key. 


If compression has been used, then conventional encryption is applied to the com- 
pressed data packet format from the compression of the signature packet and the literal 
data packet. Otherwise, conventional encryption is applied to the block consisting of the 
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Exs, : Encryption with user a’s private key 


E KP, * Encryption with user b’s public key 








Figure 9.5 PGP message format. 


signature packet and the literal data packet. In either case, the ciphertext is referred to as 
a conventional-key-encrypted data packet. 
As shown in Figure 9.5, the entire block of PGP message is usually encoded with 


radix-64 encoding 


9.1.7 Key Material Packet 


A key material packet contains all the information about a public or private key. There 
are four variants of this packet type and two versions. 


9.1.7.1 Key Packet Variants 


There are: 


e Public-key packet (tag 6): This packet starts a series of packets that forms a PGP 


5.x key. 


e Public subkey packet (tag 14): This packet has exactly the same format as a public- 
key packet, but denotes a subkey. One or more subkeys may be associated with a 
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top-level key. The top-level key provides signature services, and the subkeys provide 
encryption services. PGP 2.6.x ignores public-subkey packets. 

e Secret-key packet (tag 5): This packet contains all the information that is found in a 
public-key packet, including the public-key materials, but also includes the secret-key 
material after all the public-key fields. 

e Secret-subkey packet (tag 7): A secret-subkey packet is the subkey analogous to the 
secret-key packet and has exactly the same format. 


9.1.7.2 Public-key Packet Formats 


There are two variants of version 3 packets and version 2 packets. Version 3 packets were 
originally generated by PGP 2.6. Version 2 packets are identical in format to version 3 
packets, but are generated by PGP 2.5. However, v2 keys are deprecated and they must 
not be generated. PGP 5.0 introduced version 4 packets, with new fields and semantics. 
PGP 2.6.x will not accept key-material packets with versions greater than 3. PGP 5.x 
(or PGP3) implementation should create keys with version 4 format, but v4 keys correct 
some security deficiencies in v3 keys. 
A v3 key packet contains: 


A one-octet version number (3). 

A four-octet number denoting the time that the key was created. 

A two-octet number denoting the time in days that this key is valid. 

A one-octet number denoting the public-key algorithm of this key. 

A series of multiprecision integers (MPIs) comprising the key material: an MPI of 
RSA public module n; an MPI of RSA public encryption exponent e. 


A key ID is an eight-octet scalar that identifies a key. For a v3 key, the eight-octet 
key ID consists of the low 64 bits of the public modulus of the RSA key. The fingerprint 
of a v3 key is formed by hashing the body (excluding the two-octet length) of the MPIs 
that form the key material with MDS. 

Note that MPIs are unsigned integers. An MPI consists of two parts: a two-octet scalar 
that is the length of the MPI in bits followed by a string of octets that contain the 
actual integer. 


Example 9.4 Suppose the string of octets [0009 01ff] forms an MPI. The length of the 
MPI in bits is [00000000 00001001] or 9 (= 23 + 2°) in octets. The actual integer value 
of the MPI is: 


[O1ff] = 2° + 27 + 2°4 2° 4.24423 42742'42°=511 
The MPI size is: 
((MPI. length + 7)/8) +2 = (9+ 7)/8) + 2 = 4 octets 


which checks the given size of the MPI string. 
The v4 format is similar to the v3 format except for the absence of a validity period. 
Fingerprints of v4 keys are calculated differently from v3 keys. A v4 fingerprint is the 
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160-bit SHA-1 hash of the one-octet packet tag, followed by the two-octet packet length, 
followed by the entire public-key packet starting with the version field. The key ID is the 
low-order 64 bits of the fingerprint. 


A V4 key packet contains: 


A one-octet version number (4). 

A four-octet number denoting the time that the key was created. 
A one-octet number denoting the public-key algorithm of this key. 
A series of MPIs comprising the key material: 


—  Algorithm-specific fields for RSA public keys: MPI of RSA public modulus n; 
MPI of RSA public encryption exponent e. 

—  Algorithm-specific fields for DSA public keys: MPI of DSA prime p; MPI of 
DSA group order g (g is a prime divisor of p — 1); MPI of DSA group generator 
g; MPI of DSA public key value y = g* where x is secret. 

—  Algorithm-specific fields for ElGamal public keys: MPI of ElGamal prime p; 
MPI of ElGamal group generator g; MPI of ElGamal public key value y = g* 
where x is secret. 


9.1.7.3 Secret-key Packet Formats 


The secret-key and secret-subkey packets contain all the data of public-key and public- 
subkey packets in encrypted form, with additional algorithm-specific key data appended. 


The secret-key packet contains: 


A public-key or public-subkey packet, as described above. 

One octet indicating string-to-key (S2K) usage conventions: 0 indicates that the secret- 
key data is not encrypted; 255 indicates that an S2K specifier is being given. Any 
other value specifies a symmetric-key encryption algorithm. 

If the S2K usage octet was 255, a one-octet symmetric encryption algorithm (optional). 
If the S2K usage octet was 255, an S2K specifier (optional). The length of the S2K 
specifier is implied by its type, as described above. 

If secret data is encrypted, an eight-octet IV (optional). 

Encrypted MPIs comprising the secret-key data. These algorithm-specific fields are as 
described below. 

A two-octet checksum of the plaintext of the algorithm-specific portion (sum of all 
octets, mod 2!° = mod 65 536): 


—  Algorithm-specific fields for RSA secret keys: MPI of RSA secret exponent d; 
MPI of RSA secret prime value p; MPI of RSA secret prime value g (p < q); 
MPI of u, the multiplicative inverse of p, mod q. 

—  Algorithm-specific fields for DSA secret keys: MPI of DSA secret exponent x. 

—  Algorithm-specific fields for ElIGamal secret keys: MPI of ElGamal secret expo- 
nent x. 
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Simple S2K directly hashes the string to produce the key data: 


Octet 0: 0x00 
Octet 1: hash algorithm 


It also hashes the passphrase to produce the session key. The hashing process to be done 
depends on the size of the session key and the size of the hash algorithm’s output. If the 
hash size is greater than or equal to the session key size, the higher-order (leftmost) octets 
of the hash are used as the key. If the hash size is less than the key size, multiple instances 
are preloaded with 0, 1, 2, ... octets of zeros in order to produce the required key data. 

S2K specifiers are used to convert passphrase strings into symmetric-key encryp- 
tion/decryption keys. They are currently used in two ways: to encrypt the secret part 
of private keys in the private keyring, and to convert passphrases to encryption keys for 
symmetrically encrypted messages. 

Secret MPI values can be encrypted using a passphrase. If an S2K specifier is given, it 
describes the algorithm for converting the passphrase to a key, otherwise a simple MD5 
hash of the passphrase is used. The cipher for encrypting the MPIs is specified in the 
secret-key packet. 

Encryption/decryption of the secret data is done in CFB (Cipher Feedback) mode using 
the key created from the passphrase and IV from the packet. A different mode is used 
with v3 keys (which are only RSA) than with other key formats. With v3 keys, the prefix 
data (the first two octets) of the MPI is not encrypted; only the MPI non-prefix data is 
encrypted. Furthermore, the CFB state is resynchronised at the beginning of each new 
MPI value, so that the CFB block boundary is aligned with the start of the MPI data. With 
v4 keys, a simpler method is used: all secret MPI values are encrypted in CFB mode, 
including the MPI bitcount prefix. 

The 16-bit checksum that follows the algorithm-specific portion is the algebraic sum, 
mod 65 536, of the plaintext of all the algorithm-specific octets (including the MPI prefix 
and data). With v4 keys, the checksum is encrypted like the algorithm-specific data. This 
value is used to check that the passphrase was correct. 

Besides simple S2K, there are two more S2K specifiers currently supported: 


e Salted S2K: This includes a salt value in the simple S2K specifier that hashes the 
passphrase to help prevent dictionary attacks: 


Octet 0: 0x01 
Octet 1: hash algorithm 
Octets 2—9: eight-octet salt value 


Salted S2K is exactly like simple S2K, except that the input to the hash function 

consists of the eight octets of salt from the S2K specifier, followed by the passphrase. 

e Iterated and salted S2K: This includes both a salt and octet count. The salt is combined 

with the passphrase and the resulting value is hashed repeatedly. This further increases 
the amount of work an attacker would have to do. 


Octet 0: 0x03 
Octet 1: hash algorithm 
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Octets 2—9: eight-octet salt value 


Octet 10: count, a one-octet, 


Iterated—salted S2K hashes the passphrase and salt data multiple times. The total 
number of octets to be hashed is given in the encoded count in the S2K specifier. But 
an octet count of how many octets will be hashed, not an 
iteration count. The salt followed by the passphrase data is repeatedly hashed until 
the number of octets specified by the octet count has been hashed. Implementations 
should use salted or iterated—salted S2K specifiers because simple S2K specifiers are 


the resulting count value is 


coded value. (The count is coded into a one-octet number.) 


more vulnerable to dictionary attacks. 


9.1.8 Algorithms for PGP 5.x 


This section describes the algorithms used in PGP 5.x. 


9.1.8.1 Public-Key Algorithms 


ID 


21 
100-110 


Algorithm 


RSA (encrypt or sign) 

RSA encryption only 

RSA sign only 

ElGamal (encrypt only) 

DSA (DSS) 

Reserved for elliptic curve 
Reserved for ECDSA 
ElGamal (encrypt or sign) 
Reserved for Diffie-Hellman 
Private/experimental algorithm 


9.1.8.2 Symmetric-Key Algorithms 


ID 


DnB WN KY CO 


Algorithm 


Plaintext or unencrypted data 
IDEA 

Triple DES (DES—EDE) 

CAST 5 (128-bit key) 

Blowfish (128-bit key, 16 rounds) 
SAFER-SK128 (13 rounds) 
Reserved for DES/SK 
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ID Algorithm 
7 Reserved for AES (128-bit key) 
8 Reserved for AES (192-bit key) 
9 Reserved for ASE (256-bit key) 
100-110 Private/experimental algorithm 


9.1.8.3 Compression Algorithm 


ID Algorithm 
0 Uncompressed 
1 ZIP (RFC 1951) 
2 ZLIB (RFC 1950) 
100-110 Private/experimental algorithm 


9.1.8.4 Hash Algorithms 


ID Algorithm 

1 MD5 

2 SHA-1 

3 RIPE-MD/160 

4 Reserved for double-width SAH (experimental) 
5) MD2 

6 Reserved for TIGER/192 

7 Reserved for HAVAL (5 pass, 160-bit) 

100-110 Private/experimental algorithm 


These tables are not an exhaustive list. An implementation may utilise an algorithm 
not on these lists. 


9.2 S/MIME 


Secure/Multipurpose Internet Mail Extension (S/MIME) provides a consistent means to 
send and receive secure MIME data. S/MIME, based on the Internet MIME standard, is a 
security enhancement to cryptographic electronic messaging. Further, S/MIME not only 
is restricted to e-mail, but can be used with any transport mechanism that carries MIME 
data, such as HTTP. As such, S/MIME takes advantage of allowing secure messages 
to be exchanged in mixed-transport systems. Therefore, it appears likely that S/MIME 
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will emerge as the industry standard for commercial and organisational use. This section 
describes a protocol for adding digital signature and encryption services to MIME data. 


9.2.1 MIME 


SMTP is a simple mail transfer protocol by which messages are sent only in NVT (Net- 
work Virtual Terminal) 7-bit ASCII format. NVT normally uses what is called NVT 
ASCII. This is an 8-bit character set in which the seven lowest-order bits are the same as 
ASCII and the highest-order bit is zero. 

MIME was defined to allow transmission of non-ASCII data through e-mail. MIME 
allows arbitrary data to be encoded in ASCII and then transmitted in a standard e-mail mes- 
sage. It is a supplementary protocol that allows non-ASCII data to be sent through SMTP. 
However, MIME is not a mail protocol and cannot replace SMTP; it is only an extension 
to SMTP. In fact, MIME does not change SMTP or POP3, neither does it replace them. 

The MIME standard provides a general structure for the content type of Internet mes- 
sages and allows extensions for new content-type applications. To accommodate arbitrary 
data types and representations, each MIME message includes information that tells the 
recipient the type of the data and the encoding used. The MIME standard specifies that 
a content-type declaration must contain two identifiers, a content type and a subtype, 
separated by a slash. 


9.2.1.1. MIME Description 


MIME transforms non-ASCII data at the sender’s site to NVT ASCII data and delivers 
it to the client SMTP to be sent through the Internet. The server SMTP at the receiver’s 
site receives the NVT ASCII data and delivers it to MIME to be transformed back to the 
original non-ASCII data. Figure 9.6 illustrates a set of software functions that transforms 
non-ASCII data to ASCII data and vice versa. 


9.2.1.2 MIME Header 
MIME defines five headers that can be added to the original SMTP header section: 


e MIME_Version 
e Content_Type 
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Figure 9.6 MIME showing a set of transforming functions. 
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Original header 





MIME header 
MIME Version: 1.1 
Content Type: type/subtype 
Content Transfer Encoding: encoding type 
Content ID: message ID 
Content Description: textual explanation of non- textual contents 


Mail message body 








Figure 9.7. MIME header. 


e Content_Transfer_Encoding 
e Content_Id 
e Content_Description 


The MIMI header is shown in Figure 9.7 and described below. 


MIME_Version 


This header defines the version of MIME used. The current version is 1.0. 


Content_Type 


This header defines the type of data used in the message body. The content type and the 
content subtype are separated by a slash. MIME allows seven different types of data: 


Text: The original message is in 7-bit ASCII format. 

Multipart: The body contains multiple, independent parts. The multipart header needs 
to define the boundary between each part. Each part has a separate content type and 
encoding. 


The multipart/signed content type specifies how to support authentication and 
integrity services via digital signature. 
Definition of multipart/signed: 


— MIME type name: multipart 

— MIME subtype name: signed. 

— Required parameters: boundary, protocol and micalg 

— Optional parameters: none 

— Security considerations: must be treated as opaque while in transit. 


The multipart/signed content type contains exactly two body parts. The first body 
part is the one over which the digital signature was created, including its MIME 
headers. The second body part contains the control information necessary to verify 
the digital signature. 
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Definition of multipart/encrypted: 


— MIME type name: multipart 

— MIME subtype name: encrypted 

— Required parameters: boundary and protocol 
— Optional parameters: none 

— Security considerations: none. 


The multipart/encrypted content type contains exactly two body parts. The first 
body part contains the control information necessary to decrypt the data in the sec- 
ond body part and is labelled according to the value of the protocol parameter. 
The second body part contains the data which was encrypted and is always labelled 
application/octet-stream. 


Message: In the message type, the body is itself a whole mail message, a part of a mail 
message or a pointer to the message. Three subtypes are currently used: RFC 2822, 
partial or external body. The subtype RFC 2822 is used if the body is encapsulating 
another message. The subtype partial is used if the original message has been frag- 
mented into different mail messages and this mail message is one of the fragments. 
The fragments must be reassembled at the destination by MIME. Three parameters 
must be added: ID, number and total. The id identifies the message and is present in 
all the fragments. The number defines the sequence order of the fragment. The fotal 
defines the number of fragments that comprise the original message. 


Image: The original message is a stationary image, indicating that there is no anima- 
tion. The two subtypes currently used are Joint Photographic Experts Group (JPEG), 
which uses image compression, and Graphics Interchange Format (GIF). 


Video: The original message is a time-varying image (animation). The only subtype 
is Motion Picture Experts Group (MPEG). If the animated image contains sound, it 
must be sent separately using the audio content type. 


Audio: The original message contains sound. The only subtype is basic, which uses 
8 kHz standard audio data. 


Application: The original message is a type of data not previously defined. There are 
only two subtypes used currently: octet-stream and PostScript. Octet-stream is used 
when the data represents a sequence of binary data consisting of 8-bit bytes. PostScript 
is used when the data is in Adobe PostScript format for printers that support PostScript. 


Content_Transfer_Encoding 


This header defines the method to encode the messages into ones and zeros for transport. 
There are the five types of encoding: 7 bit, 8 bit, binary, Base64 and Quoted-printable. 
Table 9.3 describes the Content_Transfer_Encoding by the five types. 


Note that lines in the header identify the type of the data as well as the encoding used. 


7 bit: This is 7-bit NVT ASCII encoding. Although no special transformation is 
needed, the length of the line should not exceed 1000 characters. 
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Table 9.3 Five types of encoding 


Type Description 

7 bit NVT ASCII characters and short lines 

8 bit Non-ASCII characters and short lines 

Binary Non-ASCII characters with 
unlimited-length lines 

Base64 6-bit blocks of data encoded into 
8-bit ASCII characters 

Quoted-printable Non-ASCII characters encoded as an 
equals sign followed by an ASCII 
code 


& bit: This is 8-bit encoding. Non-ASCII characters can be sent, but the length of the 
line still should not exceed 1000 characters. Since the underlying SMTP is able to 
transfer 8-bit non-ASCII characters, MIME does not do any encoding here. Base64 
(or radix-64) and quoted-printable types are preferable. 

Binary: This is 8-bit encoding. Non-ASCII characters can be sent, and the length of the 
line can exceed 1000 characters. MIME does not do any encoding here; the underlying 
SMTP must be able to transfer binary data. Therefore, it is not recommended. Base64 
(or radix-64) and quoted-printable types are preferable. 

Base64: This is a solution for sending data made of bytes when the highest bit is not 
necessarily zero. Base64 transforms this type of data of printable characters which 
can be sent as ASCII characters. 

Quoted-printable: Base64 is a redundant encoding scheme. The 24-bit non-ASCII data 
becomes four characters consisting of 32 bits. We have an overhead of 25%. If the 
data consists of mostly ASCII characters with a small non-ASCII portion, we can use 
quoted-printable encoding. If a character is ASCII, it is sent as it is; if a character is 
not ASCII it is sent as three characters. 


Content_Id 
This header uniquely identifies the whole message in a multiple message environment: 


Content_Id: id = <content_id> 


Content_Description 


This header defines whether the body is image, audio or video: 
Content_Description: <description> 


Example 9.5 Consider an MIME message that contains a photograph in standard GIF 
representation. This GIF image is to be converted to 7-bit ASCII using Base64 encoding 
as follows: 
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From: myrhee @tsp.snu.ac.kr 

To: kiisc2 @kornet.net 

MIME Version: 1.1 

Content_Type: image/gif 
Content_Transfer_Encoding: Base64 


... data for the gif image... 


In this example, MIME-Version declares that the message was composed using version 
1.1 of the MIME protocol. The MIME standard specifies that a Content_Type declaration 
must contain two identifiers, a content type and a subtype, separated by a slash. In this 
example, image is the content type, and gif is the subtype. Therefore, the Content_Type 
declares that the data is a GIF image. For the Content_Transfer_Encoding, the header 
declares that Base64 encoding was used to convert the image to ASCII. To view the 
image, a receiver’s mail system must first convert from Base64 encoding back to binary, 
and then run an application that displays a GIF image on the user’s screen. 


9.2.1.3 MIME Security Multiparts 


An Internet e-mail message consists of two parts: the headers and the body. The headers 
form a collection of field/value pairs, while the body is defined according to the MIME 
format. The basic MIME by itself does not specify security protection. Accordingly, a 
MIME agent must provide security services by employing a security protocol mecha- 
nism, by defining two security subtypes of the MIME multipart content type: signed and 
encrypted. In each of the security subtypes, there are exactly two related body parts: one 
for the protected data and one for the control information. The type and contents of the 
control information body parts are determined by the value of the protocol parameter of 
the enclosing multipart/signed or multipart/encrypted content type. A MIME agent should 
be able to recognise a security multipart body part and to identify its protected data and 
control information body part. 

The multipart/signed content type specifies how to support authentication and integrity 
services via digital signature. The multipart/singed content type contains exactly two body 
parts. The first body part is the one over which the digital signature was created, including 
its MIME headers. The second body part contains the control information necessary to 
verify the digital signature. The Message Integrity Check (MIC) is the quantity computed 
over the body part with a message digest or hash function, in support of the digital signa- 
ture service. The multipart/encrypted content type specifies how to support confidentiality 
via encryption. The multipart/encrypted content type contains exactly two body parts. The 
first body part contains the control information necessary to decrypt the data in the second 
body part. The second body part contains the data which was encrypted and is always 
labeled application/octet-stream. 


9.2.1.4 MIME Security with OpenPGP 


This subsection describes how the OpenPGP message format can be used to provide 
privacy and authentication using the MIME security content type. The integrating work 
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on PGP with MIME suffered from a number of problems, the most significant of which 
was the inability to recover signed message bodies without parsing data structures specific 
to PGP. RFC 1847 defines security multipart formats for MIME. The security multiparts 
clearly separate the signed message body from the signature. 

PGP can generate either ASCII Armor or a stream of arbitrary 8-bit octets when 
encrypting data, generating a digital signature, or extracting public-key data. The ASCII 
Armor output is the required method for data transfer. When the data is to be transmitted 
in many parts, the MIME message/partial mechanism should be used rather than the 
multipart ASCH Armor OpenPGP format. 

Agents treat and interpret multipart/signed and multipart/encrypted as opaque, which 
means that the data is not to be altered in any way. However, many existing mail gateways 
will detect if the next hop does not support MIME or 8-bit data and perform conversion 
to either quoted-printable or Base64. This presents serious problems for multipart/signed 
where the signature is invalidated when such an operation occurs. For this reason all data 
signed according to this protocol must be constrained to 7 bits. 

Before OpenPGP encryption, the data is written in MIME canonical format (body and 
headers). OpenPGP encrypted data is denoted by the multipart/encrypted content type, 
described in Section 9.2.1.3, and must have a protocol parameter value of ‘application/pgp- 
encrypted’. The multipart/encrypted MIME body must consist of exactly two body parts, 
the first with content type ‘application/pgp-encrypted’. This body contains the control 
information. The second MIME body part must contain the actual encrypted data. It must 
be labelled with a content type of ‘application/octet-stream’ . 

OpenPGP signed messages are denoted by the multipart/signed content type, described 
in Section 9.2.1.3, with a protocol parameter which must have a value of ‘application/pgp- 
signature’. The micalg parameter for the ‘application/pgp-signature’ protocol must contain 
exactly one hash symbol of the format ‘pgp-<hash-identifier>’ where <hash-identifier> 
identifies the MIC algorithm used to generate the signature. Hash symbols are contracted 
from text names or by converting the text name to lower case and prefixing it with the four 
characters ‘pgp-’. Currently defined values are ‘pgp-md5’, ‘pgp-shal’, ‘pgp-ripemd160’, 
‘pgp-tiger192’ and ‘pgp-haval-5-160’. The multipart/signed body must consist of exactly 
two parts. The first part contains the signed data in MIME canonical format, including a 
set of appropriate content headers describing the data. The second part must contain the 
OpenPGP digital signature. It must be labelled with a content type of ‘application/pgp- 
signature’. 

When the OpenPGP digital signature is generated: 


e The data to be signed must first be converted to its content-type specific canoni- 
cal form. 

e An appropriate Content_Transfer_Encoding is applied. In particular, line endings in 
the encoded data must use the canonical <CR><LF> sequence where appropriate. 

e MIME content headers are then added to the body, each ending with the canonical 
<CR><LF> sequence. 

e Any trailing white space must be removed from the signed material. 

e The digital signature must be calculated over both the data to be signed and its set of 
content headers. 
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e The signature must be generated as detached from the signed data so that the process 
does not alter the signed data in any way. 


Note that the accepted OpenPGP convention is for signed data to end with a 
<CR><LF> sequence. 
Upon receipt of a signed message, an application must: 


e Convert line endings to the canonical <CR><LF> sequence before the signature can 
be verified. 

e Pass both the signed data and its associated content headers along with the OpenPGP 
signature to the signature verification service. 


Sometimes it is desirable both to digitally sign and then to encrypt a message to be sent. 
This encrypted and signed data protocol allows for two ways of accomplishing this task: 


e The data is first signed as a multipart/signature body, and then encrypted to form 
the final multipart/encrypted body. This is most useful for standard MIME-compliant 
message forwarding. 

e The OpenPGP packet format describes a method for signing and encrypting data in 
a single OpenPGP message. This method is allowed in order to reduce processing 
overheads and increase compatibility with non-MIME implementations of OpenPGP. 
The resulting data is formatted as a ‘multipart/encrypted’ object. Messages which 
are encrypted and signed in this combined fashion are required to follow the same 
canonicalisation rules as multipart/singed object. It is explicitly allowed for an agent 
to decrypt a combined message and rewrite it as a multipart/signed object using the 
signature data embedded in the encrypted version. 


A MIME body part of the content type ‘application/pgp-keys’ contains ASCII-Armour- 
ed transferable public-key packets as defined in RFC 2440. 

Signatures of a canonical text document as defined in RFC 2440 ignore trailing white 
space in signed material. Implementations which choose to use signatures of canonical 
text documents will not be able to detect the addition of white space in transit. 


9.2.2 S/MIME 


S/MIME provides a way to send and receive 7-bit MIME data. S/MIME can be used 
with any system that transports MIME data. It can also be used by traditional mail 
user agents (MUAs) to add cryptographic security services to mail that is sent, and to 
interpret cryptographic security services in mail that is received. In order to create S/MIME 
messages, an S/MIME agent has to follow the specifications discussed in this section, as 
well as the specifications listed in the cryptographic message syntax (CMS). 

The S/MIME agent represents user software that is a receiving agent, a sending agent, 
or both. S/MIME version 3 agents should attempt to have the greatest interoperability 
possible with S/MIME version 2 agents. S/MIME version 2 is described in RFC 2311 to 
RFC 2315 inclusively. 
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Before using a public key to provide security services, the S/MIME agent must certify 


that the public key is valid. S/MIME agents must use the Internet X.509 Public-Key Infras- 
tructure (PKIX) certificates to validate public keys as described in the PKIX certificate 
and CRL profile. 


9.2.2.1. Definitions 


The following definitions are to be applied: 


ASN.1: Abstract Syntax Notation One, as defined in ITU-T X.680- 689. 

BER: Basic Encoding Rules for ASN.1, as defined in ITU-T X.690. 

DER: Distinguished Encoding Rules for ASN.1, as defined in ITU-T X.690. 
Certificate: A type that binds an entity’s distinguished name to a public key with a 
digital signature. This type is defined in the PKIX certificate and CRL profile. The 
certificate also contains the distinguished name of the certificate issuer (the signer), 
an issuer-specific serial number, the issuer’s signature algorithm identifier, a validity 
period and extensions also defined in that certificate. 

CRL: The Certificate Revocation List that contains information about certificates 
whose validity the issuer has prematurely revoked. The information consists of an 
issuer name, the time of issue, the next scheduled time of issue, a list of certificate 
serial numbers and their associated revocation times, and extensions as defined in 
Chapter 6. The CRL is signed by the issuer. 

Attribute certificate: An X.509 AC is a separate structure from a subject’s PKIX 
certificate. A subject may have multiple X.509 ACs associated with each of its 
PKIX certificates. Each X.509 AC binds one or more attributes with one of the 
subject’s PKIXs. 

Sending agent: Software that creates S/MIME CMS objects, MIME body parts that 
contains CMS objects, or both. 

Receiving agent: Software that interprets and processes S/MIME CMS objects, MIME 
parts that contain CMS objects, or both. 

S/MIME agent: User software that is a receiving agent, a sending agent, or both. 


9.2.2.2 Cryptographic Message Syntax (CMS) Options 


CMS allows for a wide variety of options in content and algorithm support. This sub- 
section puts forth a number of support requirements and recommendations in order to 
achieve a base level of interoperability among all S/MIME implementations. CMS pro- 
vides additional details regarding the use of the cryptographic algorithms. 


DigestAlgorithmldentifier 


This type identifies a message digest algorithm which maps the message to the mes- 
sage digest. Sending and receiving agents must support SHA-1. Receiving agents should 
support MDS for the purpose of providing backward compatibility with MD5-digested 
S/MIME v2 SignedData objects. 
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SignatureAlgorithmlidentifier 


Sending and receiving agents must support id-dsa defined in DSS. Receiving agents should 
support rsaEncryption, defined in PRCS-1. 


KeyEncryptionAlgorithmldentifier 


This type identifies a key encryption algorithm under which a content encryption key can 
be encrypted. A key-encryption algorithm supports encryption and decryption operations. 
The encryption operation maps a key string to another encrypted key string under the 
control of a key encryption key. 

Sending and receiving agents must support Diffie-Hellman key exchange. Receiving 
agents should support rsaEncryption. Incoming encrypted messages contain symmetric 
keys which are to be decrypted with a user’s private key. The size of the private key is 
determined during key generation. Sending agents should support rsaEncryption. 


General syntax 


The syntax is to support six different content types: data, signed data, enveloped data, 
signed-and-enveloped data, digested data and encrypted data. There are two classes of 
content types: base and enhanced. Content types in the base class contain just data with 
no cryptographic enhancement, categorised as the data content type. Content types in the 
enhanced class contain content of some type (possibly encrypted), and other cryptographic 
enhancements. These types employ encapsulation, giving rise to the terms outer content 
containing the enhancements and inner content being enhanced. 

CMS defines multiple content types. Of these, only the data, signed data and enveloped 
data types are currently used for S/MIME. 


e Data content type: This type is arbitrary octet strings, such as ASCII text files. Such 
strings need not have any internal structure. 
The data content type should have ASN.1 type Data: 


Data ::= OCTET STRING 


Sending agents must use the id-data content-type identifier to indicate the message 
content which has had security services applied to it. 


e Signed-data content type: This type consists of any type and encrypted message digests 
of the content for zero or more signers. Any type of content can be signed by any 
number of signers in parallel. The encrypted digest for a signer is a digital signature 
on the content for that signer. Sending agents must use the signed-data content type 
to apply a digital signature to a message or in a degenerate case where there is 
no signature information to convey certificates. The syntax has a degenerate case in 
which there are no signers on the content. This degenerate case provides a means to 
disseminate certificates and certificate-revocation lists. 

The process to construct signed data is as follows. A message digest is computed 
on the content with a signer-specific message digest algorithm. A digital signature is 
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formed by taking the message digest of the content to be signed and then encrypting 
it with the private key of the signer. The content plus signature are then encoded 
using Base64 encoding. A recipient verifies the signed-data message by decrypting 
the encrypted message digest for each signer with the signer’s public key, then com- 
paring the recovered message digest to an independently computed message digest. 
The signer’s public key is either contained in a certificate included in the signer 
information, or referenced by an issuer distinguished name and an issuer-specific 
serial number that uniquely identify the certificate for the public key. 


e Enveloped-data content type: An application/prcs7-mime subtype is used for the en- 
veloped-data content type. This content type is used to apply privacy protection to a 
message. The type consists of encrypted content of any type and encrypted-content 
encryption keys for one or more recipients. The combination of encrypted content 
and encrypted content-encryption key for a recipient is called a digital envelope for 
that recipient. Any type of content can be enveloped for any number of recipients in 
parallel. If a sending agent is composing an encrypted message to a group of recipients, 
that agent is forced to send more than one message. 

The process by which enveloped data is constructed involves the following: 


— Acontent-encryption key (a pseudo-random session key) is generated at random 
and is encrypted with the recipient’s public key for each recipient. 

— The content is encrypted with the content-encryption key. Content encryption 
may require that the content be padded to a multiple of some block size. 

— The recipient-specific information values for all the recipients are combined with 
the encrypted content into an EnvelopedData value. This information is then 
encoded into Base64. 


To cover the encrypted message, the recipient first strips off the Base64 encod- 
ing. The recipient opens the envelope by decrypting one of the encrypted content- 
encryption keys with the recipient’s private key and decrypting the encrypted content 
with the recovered content-encryption key (the session key). 

A sender needs to have access to a public key for each intended message recipient 
to use this service. This content type does not provide authentication. 


e Digested-data content type: This type consists of content of any type and a message 
digest of the content. A typical application of the digested-data content type is to add 
integrity to content of the data content type, and the result becomes the content input 
to the enveloped-data content type. A message digest is computed on the content with 
a message digest algorithm. The message digest algorithm and the message digest are 
combined with the content into a DigestedData value. 

A recipient verifies the message digest by comparing the message digest to an 
independently computed message digest. 


e Encrypted-data content type: This type consists of encrypted content of any type. 
Unlike the enveloped-data content type, the encrypted-data content type has neither 
recipients nor encrypted content-encryption keys. Keys are assumed to be managed 
by other means. 
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It is expected that a typical application of the encrypted-data content type will 
be to encrypt content of the data content type for local storage, perhaps where the 
encryption key is a password. 


9.2.3. Enhanced Security Services for S/MIME 


The security services described in this section are extensions to S/MIME version 3. Some 
of the features of each service use the concept of a triple wrapped message. A triple 
wrapped message is one that has been signed, then encrypted and then signed again. The 
signers of the inner and outer signatures may be different entities or the same entity. The 
S/MIME specification does not limit the number of nested encapsulations, so there may 
be more than three wrappings. 

The inside signature is used for content integrity, non-repudiation with proof of origin, 
and binding attributes to the original content. These attributes go from the originator to 
the recipient, regardless of the number of intermediate entities such as mail list agents that 
process the message. Signed attributes can be used for access control to the inner body. 
The encrypted body provides confidentiality, including confidentiality of the attributes 
that are carried in the inside signature. 

The outside signature provides authentication and integrity for information that is pro- 
cessed hop by hop, where each hop is an intermediate entity such as a mail list agent. 
The outer signature binds attributes to the encrypted body. These attributes can be used 
for access control and routing decisions. 


9.2.3.1 Triple Wrapped Message 


The steps to create a triple wrapped message are as follows: 


Start with the original content (a message body). 

Encapsulate the original content with the appropriate MIME content-type headers. 
Sign the inner MIME headers and the original content resulting from step 2. 

Add an appropriate MIME construct to the signed message from step 3. The resulting 
message is called the inside signature. 


Aa et 


— If it is signed using multipart/signed, the MIME construct added consists of a 
content type of multipart/signed with parameters, the boundary, the step 2 result, 
a content type of application/pkcs7-signature, optional MIME headers, and a 
body part that is the result of step 3. 

— If it is instead signed using application/pkcs7-mime, the MIME construct added 
consists of a content type of application/pkcs7-mime with parameters, optional 
MIME headers and the result of step 3. 


5. Encrypt the step 4 result as a single block, turning it into an application/pkcs7- 
mime object. 

6. Add the appropriate MIME headers: a content type of application/pkcs7-mime with 
parameters, and optional MIME headers such as Content-Transfer-Encoding and 
Content-Disposition. 

7. Sign the step 6 result (the MIME headers and the encrypted body) as a single block. 
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8. Using the same logic as in step 4, add an appropriate MIME construct to the signed 
message from step 7. The resulting message is called the outside signature, and is 
also the triple wrapped message. 


A triple wrapped message has many layers of encapsulation. The structure differs 
depending on the choice of format for the signed portions of the message. Because of the 
way that MIME encapsulates data, the layers do not appear in order, and the notion of 
layers becomes vague. 

There is no need to use the multipart/signed format in an inner signature because 
it is known that the recipient is able to process S/MIME messages. A sending agent 
might choose to use the multipart/signed format in the outer layer so that a non-S/MIME 
agent could see that the next inner layer is encrypted. Because many sending agents 
always use multipart/signed structures, all receiving agents must be able to interpret either 
multipart/signed or application/pkcs7-mime signature structures. 


9.2.3.2 Security Services with Triple Wrapping 


This subsection briefly describes the relationship of each service with triple wrapping. If 
a signed receipt is requested for a triple wrapped message, the receipt request must be in 
the inside signature, not in the outside signature. A secure mailing list agent may change 
the receipt policy in the outside signature of a triple wrapped message when the message 
is processed by the mailing list. 

A security label is included in the signed attributes of any SignedData object. A security 
label attribute may be included in either the inner signature or the outer signature, or both. 

The inner security label is used for access control decisions related to the original 
plaintext content. The inner signature provides authentication and cryptographically pro- 
tects the integrity of the original signer’s security label that is in the inside body. The 
confidentiality security service can be applied to the inner security label by encrypting the 
entire inner SignedData block within an EnvelopedData block. The outer security label 
is used for access control and routing decisions related to the encrypted message. 

Secure mail list message processing depends on the structure of S/MIME layers present 
in the message sent to the mail list agent. The agent never changes the data that was hashed 
to form the inner signature, if such a signature is present. If an outer signature is present, 
then the agent will modify the data that was hashed to form that outer signature. 

Contain attributes should be placed in the inner or outer SignedData message. Some 
attributes must be signed, while signing is optional for others, and some attributes must 
not be signed. 

Some security gateways sign messages that pass through them. If the message is of 
any type other than a SignedData type, the gateway has only one way to sign the message 
by wrapping it with a SignedData block and MIME headers. If the message to be signed 
by the gateway is a SignedData message already, the gateway can sign the message by 
inserting SignerInfo into the SignedData block. 


9.2.3.3 Signed Receipts 


Returning a signed receipt provides to the originator proof of delivery of a message, 
and allows the originator to demonstrate to a third party that the recipient was able to 


ELECTRONIC MAIL SECURITY: PGP, S/MIME 337 


verify the signature of the original message. This receipt is bound to the original message 
through the signature. Consequently, this service may be requested only if a message is 
signed. The receipt sender may optionally also encrypt a receipt to provide confidentiality 
between the sender and recipient of the receipt. 

The originator of a message may request a signed receipt from the message’s recipients. 
The request is indicated by adding a receiptRequest attribute to the signedAttributes field 
of the SignerInfo object for which the receipt is requested. The receiving user agent 
software should automatically create a signed receipt when requested to do so, and return 
the receipt in accordance with mailing list expansion options, local security policies and 
configuration options. 

Receipts involve the interaction of two parties: the sender and the receiver. The sender 
is the agent that sent the original message that includes a request for a receipt. The receiver 
is the party that received that message and generated the receipt. 

The interaction steps in a typical transaction are: 


1. Sender creates a signed message including a receipt request attribute. 
Sender transmits the resulting message to the recipient(s). 

3. Recipient receives message and determines if there are a valid signature and receipt 
request in the message. 

4. Recipient creates a signed receipt. 

Recipient transmits the resulting signed receipt message to the sender. 

6. Sender receives the message and validates that it contains a signed receipt for the 
original message. 


na 


9.2.3.4 Receipt Request Creation 


Multilayer S/MIME messages may contain multiple SignedData layers. Receipts are 
requested only for the innermost SignedData layer in a multilayer S/MIME message 
such as a triple wrapped message. Only one receipt request attribute can be included in 
the signedAttributes of SignerInfo. 


10 


Internet Firewalls for Trusted Systems 


A firewall is a device or group of devices that controls access between networks. A 
firewall generally consists of filters and gateway(s), varying from firewall to firewall. It 
is a security gateway that controls access between the public Internet and an intranet 
(a private internal network) and is a secure computer system placed between a trusted 
network and an untrusted internet. A firewall is an agent which screens network traffic in 
some way, blocking traffic it believes to be inappropriate, dangerous, or both. The security 
concerns that inevitably arise between the sometimes hostile Internet and secure intranets 
are often dealt with by inserting one or more firewalls in the path connecting the Internet 
and the internal network. In reality, Internet access provides benefits to individual users, 
government agencies and most organisations. But this access often creates a threat as a 
security flaw. The protective device that has been widely accepted is the firewall. When 
inserted between the private intranet and the public Internet it establishes a controlled 
link and erects an outer security wall or perimeter. The aim of this wall is to protect 
the intranet from Internet-based attacks and to provide a choke point where security can 
be imposed. 

Firewalls act as an intermediate server in handling SMTP and HTTP connections in 
either direction. Firewalls also require the use of an access negotiation and encapsulation 
protocol such as SOCKS to gain access to the Internet, the intranet, or both. Many 
firewalls support tri-homing, allowing use of a DMZ network. It is possible for a firewall 
to accommodate more than three interfaces, each attached to a different network segment. 

Firewalls can be classified into three main categories: packet filters, circuit-level gate- 
ways and application-level gateways. 


10.1 Role of Firewalls 


The firewall imposes restrictions on packets entering or leaving the private network. All 
traffic from inside to outside, and vice versa, must pass through the firewall, but only 
authorised traffic will be allowed to pass. Packets are not allowed through unless they 
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conform to a filtering specification, or unless there is negotiation involving some sort of 
authentication. The firewall itself must be immune to penetration. 

Firewalls create checkpoints (or choke points) between an internal private network and 
an untrusted Internet. Once the choke points have been clearly established, the device can 
monitor, filter and verify all inbound and outbound traffic. 

The firewall may filter on the basis of IP source and destination addresses and TCP port 
number. Firewalls may block packets from the Internet side that claim a source address 
of a system on the intranet, or they may require the use of an access negotiation and 
encapsulation protocol like SOCKS to gain access to the intranet. 

The means by which access is controlled relate to using network layer or transport 
layer criteria such as IP subnet or TCP port number, but there is no reason that this must 
always be so. A growing number of firewalls control access at the application layer, using 
user identification as the criterion. In addition, firewalls for ATM networks may control 
access based on the data link layer criteria. 

The firewall also enforces logging, and provides alarm capacities as well. By plac- 
ing logging services at firewalls, security administrators can monitor all access to and 
from the Internet. Good logging strategies are one of the most effective tools for proper 
network security. 

Firewalls may block TELNET or RLOGIN connections from the Internet to the intranet. 
They also block SMTP and FTP connections to the Internet from internal systems not 
authorised to send e-mail or to move files. 

The firewall provides protection from various kinds of IP spoofing and routing attacks. 
It can also serve as the platform for IPsec. Using the tunnel mode capability, the firewall 
can be used to implement Virtual Private Networks (VPNs). A VPN encapsulates all the 
encrypted data within an IP packet. 

A firewall can limit network exposure by hiding the internal network systems and 
information from the public Internet. 

The firewall is a convenient platform for security-unrelated events such as a network 
address translator (which maps local addresses to Internet addresses) and has a network 
management function that accepts or logs Internet usage. 

The firewall certainly has some negative aspects: it cannot protect against internal 
threats such as an employee who cooperates with an external attacker; it is also unable to 
protect against the transfer of virus-infected programs or files because it is impossible for it 
to scan all incoming files, e-mail and messages for viruses. However, since a firewall acts 
as a protocol endpoint, it may use an implementation methodology designed to minimise 
the likelihood of bugs. 

A firewall can effectively implement and control the traversal of IP multicast traffic. 
Some firewall mechanisms such as SOCKS are less appropriate for multicast because they 
are designed specifically for unicast traffic. 


10.2 Firewall-Related Terminology 


To design and configure a firewall, some familiarity with the basic terminology is required. 
It is useful for readers to understand the important terms commonly applicable to firewall 
technologies. 
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10.2.1 Bastion Host 


A bastion host is a publicly accessible device for the network’s security, which has a 
direct connection to a public network such as the Internet. The bastion host serves as a 
platform for any one of the three types of firewalls: packet filter, circuit-level gateway or 
application-level gateway. 

Bastion hosts must check all incoming and outgoing traffic and enforce the rules 
specified in the security policy. They must be prepared for attacks from external and 
possibly internal sources. They should be built with the least amount of hardware and 
software in order for a potential hacker to have less opportunity to overcome the firewall. 
Bastion hosts are armed with logging and alarm features to prevent attacks. 

The bastion host’s role falls into the following three common types: 


e Single-homed bastion host: This is a device with only one network interface, normally 
used for an application-level gateway. The external router is configured to send all 
incoming data to the bastion host, and all internal clients are configured to send 
all outgoing data to the host. Accordingly, the host will test the data according to 
security guidelines. 


e Dual-homed bastion host: This is a firewall device with at least two network interfaces. 
Dual-homed bastion hosts serve as application-level gateways, and as packet filters 
and circuit-level gateways as well. The advantage of using such hosts is that they 
create a complete break between the external network and the internal network. This 
break forces all incoming and outgoing traffic to pass through the host. The dual- 
homed bastion host will prevent a security break-in when a hacker tries to access 
internal devices. 


e Multihomed bastion host: Single-purpose or internal bastion hosts can be classified 
as either single-homed or multihomed bastion hosts. The latter are used to allow 
the user to enforce strict security mechanisms. When the security policy requires all 
inbound and outbound traffic to be sent through a proxy server, a new proxy server 
should be created for the new streaming application. On the new proxy server, it 
is necessary to implement strict security mechanisms such as authentication. When 
multihomed bastion hosts are used as internal bastion hosts, they must reside inside 
the organisation’s internal network, normally as application gateways that receive 
all incoming traffic from external bastion hosts. They provide an additional level of 
security in case the external firewall devices are compromised. All the internal network 
devices are configured to communicate only with the internal bastion host. 


e A tri-homed firewall connects three network segments with different network 
addresses. This firewall may offer some security advantages over firewalls with two 
interfaces. An attacker on the unprotected Internet may compromise hosts on the DMZ 
but still not reach any hosts on the protected internal network. 


10.2.2 Proxy Server 


Proxy servers are used to communicate with external servers on behalf of internal clients. 
A proxy service is set up and torn down in response to a client request, rather than 
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existing on a static basis. The term proxy server typically refers to an application-level 
gateway, although a circuit-level gateway is also a form of proxy server. The gateway 
can be configured to support an application-level proxy on inbound connections and a 
circuit-level proxy on outbound connections. Application proxies forward packets only 
when a connection has been established using some known protocol. When the connection 
closes, a firewall using application proxies rejects individual packets, even if they contain 
port numbers allowed by a rule set. In contrast, circuit proxies always forward packets 
containing a given port number if that port number is permitted by the rule set. Thus, the 
key difference between application and circuit proxies is that the latter are static and will 
always set up a connection if the DUT/SUT’s rule set allows it. Each proxy is configured 
to allow access only to specific host systems. 

The audit log is an essential tool for detecting and terminating intruder attacks. There- 
fore, each proxy maintains detailed audit information by logging all traffic, each connec- 
tion and the duration of each connection. 

Since a proxy module is a relatively small software package specifically designed for 
network security, it is easier to check such modules for security flaws. 

Each proxy is independent of other proxies on the bastion host. If there is a problem 
with the operation of any proxy, or if future vulnerability is discovered, it is easy to replace 
the proxy without affecting the operation of the proxy’s applications. If the support of a 
new service is required, the network administrator can easily install the required proxy 
on the bastion host. 

A proxy generally performs no disk access other than to read its initial configuration 
file. This makes it difficult for an intruder to install Trojan horse sniffers or other dangerous 
files on the bastion host. 


10.2.3 SOCKS 


The SOCKS protocol version 4 provides for unsecured firewall traversal for TCP-based 
client/server applications, including HTTP, TELNET and FTP. The new protocol extends 
the SOCKS version 4 model to include UDP, and allows the framework to include pro- 
vision for generalised strong authentication schemes, and extends the addressing scheme 
to encompass domain name and IPv6 addresses. The implementation of the SOCKS pro- 
tocol typically involves the recompilation or relinking of TCP-based client applications 
so that they can use the appropriate encapsulation routines in the SOCKS library (refer 
to RFC 1928). 

When a TCP-based client wishes to establish a connection to an object that is reachable 
only via a firewall, it must open a TCP connection to the appropriate SOCKS port on the 
SOCKS server system. The SOCKS service is conventionally located at TCP port 1080. If 
the connection request succeeds, the client enters negotiation for the authentication method 
to be used, authenticates with the chosen method, and then sends a relay request. The 
SOCKS server evaluates the request, and either establishes the appropriate connection 
or denies it. In fact, SOCKS defines how to establish authenticated connections, but 
currently it does not provide a clear-cut solution to the problem of encrypting the data 
traffic. Since the Internet at large is considered a hostile medium, encryption by using 
ESP is also assumed in this scenario. An ESP transform that provides both authentication 
and encryption could be used, in which case the AH need not be included. 
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10.2.4 Choke Point 


The most important aspect of firewall placement is to create choke points. A choke 
point is the point at which a public internet can access the internal network. The most 
comprehensive and extensive monitoring tools should be configured on the choke points. 
Proper implementation requires that all traffic be funnelled through these choke points. 
Since all traffic is flowing through the firewalls, security administrators, as a firewall 
strategy, need to create choke points to limit external access to their networks. Once 
these choke points have been clearly established, the firewall devices can monitor, filter 
and verify all inbound and outbound traffic. 

Since a choke point is installed at the firewall, a prospective hacker will go through 
the choke point. If the most comprehensive logging devices are installed in the firewall 
itself, all hacker activities can be captured. Hence, this will detect exactly what a hacker 
is doing. 


10.2.5 De-militarised Zone (DMZ) 


The DMZ is an expression that originates from the Korean War. It meant a strip of land 
forcibly kept clear of enemy soldiers. In terms of a firewall, the DMZ is a network that 
lies between an internal private network and the external public network. DMZ networks 
are sometimes called perimeter networks. A DMZ is used as an additional buffer to further 
separate the public network from the internal network. 

A gateway is a machine that provides relay services to compensate for the effects of a 
filter. The network inhabited by the gateway is often called the DMZ. A gateway in the 
DMZ is sometimes assisted by an internal gateway. The internal filter is used to guard 
against the consequences of a compromised gateway, while the outside filter can be used 
to protect the gateway from attack. 

Many firewalls support tri-homing, allowing use of a DMZ network. It is possible 
for a firewall to accommodate more than three interfaces, each attached to a different 
network segment. 


10.2.6 Logging and Alarms 


Logging is usually implemented at every device in the firewall, but these individual 
logs combine to become the entire record of user activity. Packet filters normally do 
not enable logging by default so as not to degrade performance. Packet filters as well 
as circuit-level gateways log only the most basic information. Since a choke point is 
installed at the firewall, a prospective hacker will go through the choke point. If so, the 
comprehensive logging devices will probably capture all hacker activities, including all 
user activities as well. The user can then tell exactly what a hacker is doing, and have 
such information available for audit. The audit log is an essential tool for detecting and 
terminating intruder attacks. 

Many firewalls allow the user to preconfigure responses to unacceptable activities. The 
firewall should alert the user by several means. The two most common actions are for 
the firewall to break the TCP/IP connection, or to have it automatically set off alarms. 
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10.2.7. VPN 


Some firewalls are now providing VPN services. VPNs are appropriate for any organ- 
isation requiring secure external access to internal resources. All VPNs are tunnelling 
protocols in the sense that their information packets or payloads are encapsulated or tun- 
nelled into the network packets. All data transmitted over a VPN is usually encrypted 
because an opponent with access to the Internet could eavesdrop on the data as it trav- 
els over the public network. The VPN encapsulates all the encrypted data within an IP 
packet. Authentication, message integrity and encryption are very important fundamen- 
tals for implementing a VPN. Without such authentication procedures, a hacker could 
impersonate anyone and then gain access to the network. Message integrity is required 
because the packets can be altered as they travel through the Internet. Without encryption, 
the information may become truly public. Several methods exist to implement a VPN. 
Windows NT or later versions support a standard RSA connection through a VPN. Spe- 
cialised firewalls or routers can be configured to establish a VPN over the Internet. New 
protocols such as IPsec are expected to standardise on a specific VPN solution. Several 
VPN protocols exist, but the Point-to-Point Tunnelling Protocol (PPTP) and IPsec are the 
most popular. 


10.3 Types of Firewalls 


As mentioned above, firewalls are classified into three common types: packet filters, 
circuit-level gateways and application-level gateways. We examine each of these in turn. 


10.3.1 Packet Filters 


Packet filters are one of several different types of firewalls that process network traffic on 
a packet-by-packet basis. A packet filter’s main function is to filter traffic from a remote 
IP host, so a router is needed to connect the internal network to the Internet. A packet 
filter is a device which inspects or filters each packet at a screening router for the content 
of IP packets. The screening router is configured to filter packets from entering or leaving 
the internal network, as shown in Figure 10.1. The routers can easily compare each IP 
address to a filter or a series of filters. The type of router used in a packet-filtering firewall 
is known as a screening router. 
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Figure 10.1 A screening router for packet filtering. 
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Packet filters typically set up a list of rules that are sequentially read line by line. 
Filtering rules can be applied based on source and destination IP addresses or network 
addresses, and TCP or UDP ports. Packet filters are read and then treated on a rule-by-rule 
basis. A packet filter will provide two actions, forward or discard. If the action is in the 
forward process, the action takes place to route the packet as normal if all conditions 
within the rule are met. The discard action will block all packets if the conditions in the 
rule are not met. Thus, a packet filter is a device that inspects each packet for predefined 
content. Although it does not provide an error-correcting ability, it is almost always the 
first line of defence. When packets are filtered at the external filter, it is usually called a 
screening router. 

Since a packet filter can restrict all inbound traffic to a specific host, this restriction may 
prevent a hacker from being able to contact any other host within the internal network. 
However, the significant weakness with packet filters is that they cannot discriminate 
between good and bad packets. Even if a packet passes all the rules and is routed to the 
destination, packet filters cannot tell whether the routed packet contains good or malicious 
data. Another weakness of packet filters is their susceptibility to spoofing. In IP spoofing, 
an attacker sends packets with an incorrect source address. When this happen, replies 
will be sent to the apparent source address, not to the attacker. This might seem to be 
a problem. 


10.3.1.1 Packet-Filtering Rules 


A packet filter applies a set of rules to each incoming IP packet and then forwards or 
discards the packet. The packet filter typically sets up a list of rules which may match 
fields in the IP or TCP header. If there is a match to one of the rules, that rule is able 
to determine whether to forward or discard the packet. If there is no match to any rule, 
then two default actions (forward and discard) will be taken. 


TELNET packet filtering 


TELNET is a simple remote terminal access that allows a user to log onto a computer 
across an internet. TELNET establishes a TCP connection, and then passes keystrokes 
from the user’s keyboard directly to the remote computer as if they had been typed on a 
keyboard attached to the remote machine. TELNET also carries output from the remote 
machine back to the user’s screen. TELNET client software allows the user to specify a 
remote machine either by giving its domain name or IP address. 

TELNET can be used to administer a UNIX machine. Windows NT does not provide a 
TELNET serve with the default installation, but a third-party service can be easily added. 
TELNET sends all user names and passwords in plaintext. Experienced hackers can hijack 
a TELNET session in progress. TELNET should only be used when the user can verify 
the entire network connecting the client and server, not over the Internet. All TELNET 
traffic should be filtered at the firewall. TELNET runs on TCP port 23. 

For example, to disable the ability to TELNET into internal devices from the Internet, 
the information listed Table 10.1 tells the router to discard any packet going to or coming 
from TCP port 23. TELNET for remote access application runs on TCP port 23. It runs 
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Table 10.1 Telnet packet-filtering example 


Rule Action Source Source Destination Destination Protocol 


number IP port IP port 
1 Discard . 23 * * TCP 
Discard . a 7 23 TCP 


completely in open non-encryption, with no authentication other than the user name and 
password that are transmitted in clear. An asterisk (*) in a field indicates any value in 
that particular field. The packet-filtering rule sets are executed sequentially, from top 
to bottom. 

If a packet is passed through the filter and has a source port of 23, it will immediately 
be discarded. If a packet with a destination port of 23 is passed through this filter, it is 
discarded only after rule 2 has been applied. All other packets will be discarded. 


FTP packet filtering 


If the FTP service is to apply the same basic rule as applied to TELNET, the packet filter 
to allow or block FTP would look like Table 10.2. The FTP service is typically associated 
with using TCP ports 20 and 21. 

One approach to handling FTP connections is explained with the following rule set. 
Rule 1 allows any host with the network address 192.168.10.0 to initiate a TCP session 
on any destination IP address on port 21. Rule 2 blocks any packet originating from any 
remote address with a source port of 20 and contacting a host with a network address 
192.168.10.0 on any port less than 1024. Rule 3 allows any remote address that has a 
source port of 20 and is contacting any host with a network address of 192.168.10.0 on 
any port. Once a connection is set up, the ACK flag (ACK = 1) of a TCP segment is set 
to acknowledge segments sent from the other side. If any packet violates rule 2, it will 
be immediately discarded, and rule 3 will never be executed. 

With FTP, two TCP connections are used: a control connection to set up the file transfer 
and a data connection for the actual file transfer. The data connection uses a different port 
number to be assigned for the transfer. Remember that most servers live on low-numbered 
ports, but most outgoing calls tend to use higher-numbered ports, typically above 1024. 

FTP is the first protocol for transferring or moving files across the Internet. Like many 
of the TCP/IP protocols, FTP was not designed with security in mind. It communicates 


Table 10.2 FTP packet-filtering example 


Rule Action Source Source Destination Destination Protocol 


number IP port IP port 

1 Allow 192.168.10.0 * = 21 TCP 
Block - 20 192.168.10.0 <1024 TCP 

3 Allow = 20 192.168.10.0 = TCP 


ACK = I 
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with the server on two separate TCP ports 20 and 21. Each FTP server has a command 
channel, where the requests for data and directory listings are issued, and a data channel, 
over which the requested data is delivered. 

FTP operates in two different modes (active and passive). In active mode, an FTP 
server receives commands on TCP/IP port 21 and exchanges data with the client. When 
a client contacts an FTP server in active mode and wants to send or receive data, the 
client picks an unused local TCP port between 1024 and 65 535, tells the server over the 
command channel, and listens for the server to connect on the chosen port. The server 
opens a connection from TCP port 20 to the specified port on the client machine. Once 
the connection is established, the data is passed across. 

In passive mode, the command channel is still port 21 on the server, but the traditional 
data channel on port 20 is not used. Instead, when the client requests passive mode, the 
server picks an unused local TCP port between 1024 and 65535 and tells the client. 
The client opens a connection to that port on the server. The server is listening on that 
port for the inbound connection from the client. Once the connection is established, 
the data flows across. Thus, since the client is initiating both the command and data 
channel connections to the server, most modern browsers use passive mode FTP for 
data accessing. 


SMTP packet filtering 


The sending and transmission of mail is the responsibility of a Mail Transport Agent 
(MTA). The protocol behind nearly all MTAs is SMTP and its extension ESMTP. On 
the Internet, e-mail exchanges between mail servers are handled with SMTP. It is the 
protocol that transfers e-mail from one server to another, and it provides a basic e-mail 
facility for transferring messages among separate hosts. A host’s SMTP server accepts 
mail and examines the destination IP address to decide whether to deliver the mail locally 
or to forward it to some other machine. 

SMTP is a store/forward system, and such systems are well suited to firewall appli- 
cations. SMTP receivers use TCP port 25; SMTP senders use a randomly selected port 
above 1023. 

Most e-mail messages are addressed with hostnames instead of IP addresses, and the 
SMTP server uses DNS (Directory and Naming Services) to determine the matching IP 
address. If the same machines handle internal and external mail delivery, a hacker who 
can spoof DNS information may be able to cause mail that was intended for internal 
destinations to be delivered to an external host. A hacker who can manipulate DNS 
responses can redirect mail to a server under the control of the hacker. That server can 
then copy the mail and return it. This will introduce delays and will usually leave a trail 
in the log or message headers. Therefore, if it is desired to avoid situations where internal 
and external mail delivery are handled on the machine and internal names are resolved 
through DNS, it will be good practice to have the best configuration in which there is an 
external mail server and a separate internal mail server. The external mail server has the 
IP address of the internal mail server configured via a host file. 

Sendmail (www.sendmail.org/) is the mailer commonly used on UNIX systems. Send- 
mail is very actively supported on security issues, and has both an advantage and a 
disadvantage. Table 10.3 displays some examples of SMTP packet-filtering rule sets. 
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Table 10.3. SMTP packet-filtering examples 


Case Action Source Source Destination Destination Protocol 
host port host port 

A Allow Source gateway 25 * * TCP 

B Allow * * . 25 TCP 

Cc Allow Internal host Se * 25 TCP 

D Allow i 25 z a TCP ACK flag 


Case A: Connection to source SMTP port. Port 25 is for SMTP incoming. Inbound mail is allowed, but only 
to a gateway host. 

Case B: Connection to destination SMTP port. This rule set is intended to specify that any source host can 
send mail to the destination. A TCP packet with a destination port 25 is routed to the SMTP server 
on the destination machine. 

Case C: This rule set achieves the intended result that was not achieved in B. The rule takes advantage of a 
feature of TCP connection. This rule set states that it allows IP packets where the source IP address 
is one of a list of designated internal hosts and the destination TCP port 25. 

Case D: This rule takes advantage of a feature of TCP connections. Once a connection is set up, the ACK flag 
of a TCP segment is set to acknowledge segments sent from the destination. It also allows incoming 
packets with a source port number of 25 that include that ACK flag in the TCP segment. 


Packet filters offer their services at the network, transport and session layers of the OSI 
model. Packet filters forward or deny packets based on information in each packet’s 
header, such as the IP address or TCP port number. A packet-filtering firewall uses a 
tule set to determine which traffic should be forwarded and which should be blocked. 
Packet filters are then composed of rules that are read and treated on a rule-by-rule basis. 
Therefore, packet filtering is defined as the process of controlling access by examining 
packets based on the content of packet headers. 

The following two subsections outline the specific details with relation to the circuit- 
level and application-level gateways for respective proxy services. Proxying provides 
Internet access for a single host or a small number of hosts. The proxy server eval- 
uates requests from the client and decides which to pass on and which to disregard. 
If a request is approved, the proxy server talks to the real server on behalf of the 
client and proceeds to relay requests from the client to the real server, and to relay 
the real server’s answers back to the client. The concept of proxies is very important 
to firewall application because a proxy replaces the network IP address with another 
contingent address. 

Proxies are classified into two basic forms: 


e Circuit-level gateway 
e Application-level gateway 


Both circuit and application gateways create a complete break between the internal 
premises network and external Internet. This break allows the firewall system to examine 
everything before passing it into or out of the internal network. Each of these gateways 
will be examined in turn in the following. 
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10.3.2 Circuit-Level Gateways 


The circuit-level gateway represents a proxy server that statically defines what traffic will 
be forwarded. Circuit proxies always forward packets containing a given port number 
if that port number is permitted by the rule set. A circuit-leval gateway operates at the 
network level of the OSI model. This gateway acts as an IP address translator between 
the Internet and the internal system. The main advantage of a proxy server is its ability 
to provide Network Address Translation (NAT). NAT hides the internal IP address from 
the Internet. NAT is the primary advantage of circuit-level gateways and provides secu- 
rity administrators with great flexibility when developing an address scheme internally. 
Circuit-level gateways are based on the same principles as packet filter firewalls. When 
the internal system sends out a series of packets, these packets appear at the circuit-level 
gateway where they are checked against the predetermined rules set. If the packets do not 
violate any rules, the gateway sends out the same packets on behalf of the internal system. 
The packets that appear on the Internet originate from the IP address of the gateway’s 
external port which is also the address that receives any replies. This process efficiently 
shields all internal information from the Internet. Figure 10.2 illustrates the circuit-level 
gateway for setting up two TCP connections. 


10.3.3 Application-Level Gateways 


The application-level gateway represents a proxy server, performing at the TCP/IP appli- 
cation level, that is set up and torn down in response to a client request, rather than 
existing on a static basis. Application proxies forward packets only when a connection 
has been established using some known protocol. When the connection closes, a fire- 
wall using application proxies rejects individual packets, even if the packets contain port 
numbers allowed by a rule set. 

The application gateway analyses the entire message instead of individual packets 
when sending or receiving data. When an inside host initiates a TCP/IP connection, the 
application gateway receives the request and checks it against a set of rules or filters. 
The application gateway (or proxy server) will then initiate a TCP/IP connection with the 
remote server. The server will generate TCP/IP responses based on the request from the 
proxy server. The responses will be sent to the proxy server (application gateway) where 
the responses are again checked against the proxy server’s filters. If the remote server’s 
response is permitted, the proxy server will then forward the response to the inside host. 
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Figure 10.2  Circuit-level gateway for setting up two TCP connections. 
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Figure 10.3. Application-level gateway for acting as a relay of application-level traffic. 


Certain transport layer protocols work better than others. For example, TCP can easily 
be used through a proxy server because it is a connection-based protocol, while each UDP 
packet should be treated as an individual message because UDP is connectionless. The 
proxy server must analyse each UDP packet and apply it to the filters separately, which 
slows down the proxy process. ICMP programs are nearly impossible to proxy because 
ICMP messages do not work through an application-level gateway. For example, HTTP 
traffic is often used in conjunction with proxy servers, but an internal host could not ping 
a remote host through the proxy server. Application gateways (proxy servers) are used 
as intermediate devices when routing SMTP traffic to and from the internal network and 
the Internet. 

The main advantage of a proxy server is its ability to provide NAT for shielding the 
internal network from the Internet. Figure 10.3 illustrates the application-level gateway 
acting as a relay of the application-level traffic. 


10.4 Firewall Designs 


This section concerns how to implement a firewall strategy. The primary step in designing 
a secure firewall is obviously to prevent the firewall devices from being compromised 
by threats. To provide a certain level of security, the three basic firewall designs are 
considered: a single-homed bastion host, a dual-homed bastion host and a screened subnet 
firewall. The first two options are for creating a screened host firewall, and the third option 
contains an additional packet-filtering router to achieve another level of security. 

To achieve the most security with the least amount of effort is always desirable. When 
building firewall devices, the bastion host should keep the design simple with the fewest 
possible components, both hardware and software. A bastion host is a publicly accessible 
device. When Internet users attempt to access resources on the Internet network, the first 
device they encounter is a bastion host. Fewer running services on the bastion host will 
give a potential hacker less opportunity to overcome the firewall. Bastion hosts must 
check all incoming and outgoing traffic and enforce the rules specified in the security 
policy. Bastion hosts are armed with logging and alarm features to prevent attacks. When 
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creating a bastion host, it must be kept in mind that its role will help to decide what is 
needed and how to configure the device. 


10.4.1 Screened Host Firewall (Single-Homed Bastion Host) 


The first type of firewall is a screened host which uses a single-homed bastion host 
plus a packet-filtering router, as shown in Figure 10.4. Single-homed bastion hosts can 
be configured as either circuit-level or application-level gateways. When using either of 
these two gateways, each of which is called a proxy server, the bastion host can hide the 
configuration of the internal network. 

NAT is essentially needed for developing an address scheme internally. It is a critical 
component of any firewall strategy. It translates the internal IP addresses to IANA- 
registered addresses to access the Internet. Hence, using NAT allows network admin- 
istrators to use any internal IP address scheme. 

The screened host firewall is designed such that all incoming and outgoing information 
is passed through the bastion host. The external screening router is configured to route 
all incoming traffic directly to the bastion host as indicated in Figure 10.4. The screening 
router is also configured to route outgoing traffic only if it originates from the bastion host. 
This kind of configuration prevents internal clients from bypassing the bastion host. Thus, 
the bastion host is configured to restrict unacceptable traffic and proxy acceptable traffic. 

A single-homed implementation may allow a hacker to modify the router not to forward 
packets to the bastion host. This action would bypass the bastion host and allow the hacker 
directly into the network. But such a bypass usually does not happen because a network 
using a single-homed bastion host is normally configured to send packets only to the 
bastion host, and not directly to the Internet. 


10.4.2 Screened Host Firewall (Dual-Homed Bastion Host) 


The configuration of the screened host firewall using a dual-homed bastion host adds 
significant security, compared with a single-homed bastion host. As shown in Figure 10.5, 
a dual-homed bastion host has two network interfaces. This firewall implementation is 
secure due to the fact that it creates a complete break between the internal network and 
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Figure 10.4 Screened host firewall system (single-homed bastion host). 
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Figure 10.5 Screened host firewall system (dual-homed bastion host). 


the external Internet. As with the single-homed bastion, all external traffic is forwarded 
directly to the bastion host for processing. However, a hacker may try to subvert the 
bastion host and the router to bypass the firewall mechanisms. Even if a hacker could 
defeat either the screening router or the dual-homed bastion host, the hacker would still 
have to penetrate the other. Nevertheless, a dual-homed bastion host removes even this 
possibility. It is also possible to implement NAT for dual-homed bastion hosts. 


10.4.3 Screened Subnet Firewall 


The third implementation of a firewall is the screened subnet, which is also known as 
a DMZ. This firewall is the most secure one among the three implementations, simply 
because it uses a bastion host to support both circuit- and application-level gateways. As 
shown in Figure 10.6, all publicly accessible devices, including modem and server, are 
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Figure 10.6 Screened subnet firewall system. 
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placed inside the DMZ. This DMZ then functions as a small isolated network positioned 
between the Internet and the internal network. The screened subnet firewall contains 
external and internal screening routers. Each is configured such that its traffic flows 
only to or from the bastion host. This arrangement prevents any traffic from directly 
traversing the DMZ subnetwork. The external screening router uses standard filtering to 
restrict external access to the bastion host, and rejects any traffic that does not come from 
the bastion host. This router also uses filters to prevent attacks such as IP spoofing and 
source routing. The internal screening router also uses rules to prevent spoofing and source 
routing. Like its external counterpart, this internal router rejects incoming packets that do 
not originate from the bastion host, and sends only outgoing packets to the bastion host. 

The benefits of the screened subnet firewall are based on the following facts. First, a 
hacker must subvert three separate tri-homed interfaces when he or she wants to access the 
internal network. But it is almost infeasible. Second, the internal network is effectively 
invisible to the Internet because all inbound/outbound packets go directly through the 
DMZ. This arrangement makes it impossible for a hacker to gain information about 
the internal systems because only the DMZ is advertised in the routing tables and other 
Internet information. Third, internal users cannot access the Internet without going through 
the bastion host because the routing information is contained within the network. 


11 


SET for E-commerce Transactions 


The Secure Electronic Transaction (SET) is a protocol designed for protecting credit 
card transactions over the Internet. It is an industry-backed standard that was formed by 
MasterCard and Visa (acting as the governing body) in February 1996. To promote the SET 
standard throughout the payments community, advice and assistance for its development 
have been provided by IBM, GTE, Microsoft, Netscape, RSA, SAIC, Terisa and Verisign. 

SET relies on cryptography and X.509 v3 digital certificates to ensure message confi- 
dentiality and security. SET is the only Internet transaction protocol to provide security 
through authentication. It combats the risk of transaction information being altered in transit 
by keeping information securely encrypted at all times and by using digital certificates to 
verify the identity of those accessing payment details. The specifications of and ways to 
facilitate secure payment card transactions on the Internet are fully explored in this chapter. 


11.1 Business Requirements for SET 


This section describes the major business requirements for credit card transactions by 
means of secure payment processing over the Internet. They are listed below: 


1. Confidentiality of information (provide confidentiality of payment and order informa- 
tion): To meet these needs, the SET protocol uses encryption. Confidentiality reduces 
the risk of fraud by either party to the transaction or by malicious third parties. Card- 
holder account and payment information should be secured as it travels across the 
network. It should also prevent the merchant from learning the cardholder’s credit 
card number; this is only provided to the issuing bank. Conventional encryption by 
DES is used to provide confidentiality. 


2. Integrity of data (ensure the integrity of all transmitted data): SET combats the risk 
of transaction information being altered in transit by keeping information securely 
encrypted at all times. That is, it guarantees that no changes in message content 
occur during transmission. Digital signatures are used to ensure integrity of payment 
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information. RSA digital signatures, using SHA-1 hash codes, provide message inte- 
grity. Certain messages are also protected by HMAC using SHA-1. 


Cardholder account authentication (provide authentication that a cardholder is a legit- 
imate customer of a branded payment card account): Merchants need a way to verify 
that a cardholder is a legitimate user of a valid account number. A mechanism that 
links the cardholder to a specific payment card account number reduces the incidence 
of fraud and the overall cost of payment processing. Digital signatures and certifi- 
cates are used to ensure authentication of the cardholder account. SET uses X.509 v3 
digital certificates with RSA signatures for this purpose. 


Merchant authentication (provide authentication that a merchant can accept credit 
card transactions through its relationship with an acquiring financial institution): Mer- 
chants have no way of verifying whether the cardholder is in possession of a valid 
payment card or has the authority to be using that card. There must be a way for the 
cardholder to confirm that a merchant has a relationship with a financial institution 
(acquirer) allowing it to accept the payment card. Cardholders also need to be able to 
identify merchants with whom they can securely conduct electronic commerce. SET 
provides for the use of digital signatures and merchant certificates to ensure authen- 
tication of the merchant. SET uses X.509 v3 digital certificates with RSA signatures 
for this purpose. 


Security techniques (ensure the use of the best security practices and system design 
techniques to protect all legitimate parties in an electronic commerce transaction): 
SET utilises two asymmetric key pairs for the encryption/decryption process and 
for the creation and verification of digital signatures. Confidentiality is ensured by 
the message encryption. Integrity and authentication are ensured by the use of dig- 
ital signatures. Authentication is further enhanced by the use of certificates. The 
SET protocol utilises cryptography to provide confidentiality of message informa- 
tion, ensure payment integrity and insure identity authentication. For authentication 
purposes, cardholders, merchants and acquirers will be issued with digital certificates 
by their sponsoring CAs. Thus, SET is a well-tested specification based on highly 
secure cryptographic algorithms and protocols. 


Creation of brand-new protocol (create a protocol that neither depends on transport 
security mechanisms nor prevents their use): SET is an end-to-end protocol whereas 
SSL provides point-to-point encryption. SET does not interfere with the use of other 
security mechanisms such as IPsec and SSL/TLS. Even though both technologies 
address the issue of security, they work in different ways and provide different levels 
of security. SET was specifically developed for secure payment transactions. 


Interoperability (facilitate and encourage interoperability among software and net- 
work providers): SET uses specific protocols and message formats to provide inter- 
operability. The specification must be applicable on a variety of hardware and software 
platforms and must not include a preference for one over another. Any cardholder 
with compliant software must be able to communicate with any merchant software 
that also meets the defined standard. 
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11.2 SET System Participants 


The participants in the SET system interactions are described in this section. A discrepancy 
is found between an SET transaction and a retail or mail order transaction: in a face-to- 
face retail transaction, electronic processing begins with the merchant or the acquirer, but, 
in an SET transaction, the electronic processing begins with the cardholder. 


Cardholder: In the electronic commerce environment, consumers or corporate pur- 
chasers interact with merchants on personal computers over the Internet. A cardholder 
is an authorised holder of a payment card that has been issued by an issuer. In the card- 
holder’s interactions, SET ensures that the payment card account information remains 
confidential. 


Issuer: An issuer is a financial institution (a bank) that establishes an account for a 
cardholder and issues the payment card. The issuer guarantees payment for authorised 
transactions using the payment card. 


Merchant: A merchant is a person or organisation that offers goods or services for sale 
to the cardholder. Typically, these goods or services are offered via a Website or by 
e-mail. With SET, the merchant can offer its cardholders secure electronic interactions. 
A merchant that accepts payment cards must have a relationship with an acquirer (a 
financial institution). 


Acquirer: An acquirer is the financial institution that establishes an account with 
a merchant and processes payment card authorisation and payments. The acquirer 
provides authentication to the merchant that a given card account is active and that 
the proposed purchase does not exceed the credit limit. The acquirer also provides 
electronic transfer of payments to the merchant’s account. Subsequently, the acquirer 
is reimbursed by the issuer over some sort of payment network for electronic funds 
transfer (EFT). 


Payment gateway: A payment gateway acts as the interface between a merchant and 
the acquirer. It carries out payment authorisation services for many card brands and 
performs clearing services and data capture. A payment gateway is a device operated 
by the acquirer or a designated third party that processes merchant payment messages, 
including payment instructions from cardholders. The payment gateway functions as 
follows: it decrypts the encoded message, authenticates all participants in a transaction, 
and reformats the SET message into a format compliant with the merchant’s point of 
sale system. Note that issuers and acquirers sometimes choose to assign the processing 
of payment card transactions to third-party processors. 


Certification Authority: A CA is an entity that is trusted to issue X.509 v3 public- 
key certificates for cardholders, merchants and payment gateways. The success of 
SET will depend on the existence of a CA infrastructure available for this purpose. 
The primary functions of the CA are to receive registration requests, to process and 
approve/decline requests, and to issue certificates. A financial institution may receive, 
process and approve certificate requests for its cardholders or merchants, and forward 
the information to the appropriate payment card brand(s) to issue the certificates. 
An independent Registration Authority (RA) that processes payment card certificate 
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Figure 11.1 The SET hierarchy indicating the relationships between the participants. 


requests and forwards them to the appropriate issuer or acquirer for processing. The 
financial institution (issuer or acquirer) forwards approved requests to the payment 
card brand to issue the certificates. 


Figure 11.1 illustrates the SET hierarchy which reflects the relationships between the 
participants in the SET system, described in the preceding paragraphs. In the SET envi- 
ronment, there exists a hierarchy of CAs. The SET protocol specifies a method of trust 
chaining for entity authentication. This trust chain method entails the exchange of digital 
certificates and verification of the public keys by validating the digital signatures of the 
issuing CA. As indicated in Figure 11.1, this trust chain method continues all the way up 
to the root CA at the top of the hierarchy. 


11.3 Cryptographic Operation Principles 


SET is the Internet transaction protocol providing security by ensuring confidentiality, 
data integrity, authentication of each party and validation of the participant’s identity. To 
meet these requirements, SET incorporates the following cryptographic principles: 


e Confidentiality: This is ensured by the use of message encryption. SET relies on 
encryption to ensure message confidentiality. In SET, message data is encrypted with 
a random symmetric key which is further encrypted using the recipient’s public key. 
The encrypted message along with this digital envelope is sent to the recipient. The 
recipient decrypts the digital envelope with a private key and then uses the symmetric 
key in order to recover the original message. 
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e Integrity: This is ensured by the use of a digital signature. Using the public/private- 
key pair, data encrypted with either key can be decrypted with the other. This allows 
the sender to encrypt a message using the sender’s private key. Any recipient can 
determine that the message came from the sender by decrypting the message using 
the sender’s public key. With SET, the merchant can be assured that the order it 
received is what the cardholder entered. SET guarantees that the order information is 
not altered in transit. Note that the roles of the public and private keys are reversed 
in the digital signature process where the private key is used to encrypt for signature 
and the public key is used to decrypt for verification of signature. 


e Authentication: This is also ensured by means of a digital signature, but it is further 
strengthened by the use of a CA. When two parties conduct business transactions, 
each party wants to be sure that the other is authenticated. Before a user B accepts a 
message with a digital signature from a user A, B wants to be sure that the public key 
belongs to A. One way to secure delivery of the key is to utilise a CA to authenticate 
that the public key belongs to A. A CA is a trusted third party that issues digital 
certificates. Before it authenticates A’s claims, a CA could supply a certificate that 
offers a high assurance of personal identity. This CA may require A to confirm his 
or her identity prior to issuing a certificate. Once A has provided proof of his or 
her identity, the CA creates a certificate containing A’s name and public key. This 
certificate is digitally signed by the CA. It contains the CA’s identification information, 
as well as a copy of the CA’s public key. To get the most benefit, the public key of the 
CA should be known to as many people as possible. Thus, by trusting a single key, 
an entire hierarchy can be established in which one can have a high degree of trust. 


The SET protocol utilises cryptography to provide confidentiality of information, 
ensure payment integrity and ensure identity authentication. For authentication purposes, 
cardholders, merchants and acquirers (financial institutions) will be issued with digital 
certificates by their sponsoring CAs. The certificates are digital documents attesting to 
the binding of a public key to an individual user. They allow verification of the claim 
that a given public key does indeed belong to a given individual user. 


11.4 Dual Signature and Signature Verification 


SET introduced a new concept of digital signature called dual signatures. A dual signature is 
generated by creating the message digest of two messages: order digest and payment digest. 
Referring to Figure 11.2, the customer takes the hash codes (message digests) of both the 
order message and payment message by using the SHA-1 algorithm. These two hashes, ho 
and hy, are then concatenated and the hash code h of the result is taken. Finally, the customer 
encrypts (via RSA) the final hash code with his or her private key, Kc, creating the dual 
signature. Computation of the dual signature (DS) is shown as follows: 


DS = Ex..(h) 
where h = H(H(OM)||H(PM)) 
= H(Ao||hp) 


Ex,,(= d,) is the customer’s private signature key. 
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Figure 11.2 Dual signature and order/payment message authentication. 


Example 11.1 Computation of dual signature: 
Assume that the order message (OM) and the payment message (PM) are given, respec- 
tively, as follows: 


OM = 315a46e51283f7c647 
PM = 1325f47568 


Since SHA-1 sequentially processes blocks of 512 bits, i.e. 16 32-bit words, the message 
padding must attach to the message block to ensure that a final padded message becomes 
a multiple of 512 bits. The 160-bit message digest can be computed from hashing the 
512-bit padded message by the use of SHA-1. The padded OM and PM messages are, 
respectively, 


Padded OM (512 bits): 


315a46e5 1283f7c6 47800000 00000000 
00000000 00000000 00000000 00000000 
00000000 00000000 00000000 00000000 
00000000 00000000 00000000 00000048 
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Padded PM (512 bits): 


1325f475 68 800000 00000000 00000000 
00000000 00000000 00000000 00000000 
00000000 00000000 00000000 00000000 
00000000 00000000 00000000 00000028 


Referring to Figure 11.3, H(OM) = hy and H(PM) = hy each are obtained as follows: 


hy. ¢4511d95 4556f627 fa491c85 aS5a8cfOc  6af4f62c (160 bits) 
hy. 6e94de9c ab3cb005 35d792ca O5aac971 76a17d65 (160 bits) 


Concatenating these two hash codes and appending pads yields (ho||hp): 


c4511d95 4556f627 fa491c85 a5a8cf0c 

6af4f62c 6e94de9c ab3cb005 35d792ca 
O5aac971 76a17d65 80000000 00000000 
00000000 00000000 00000000 00000 140 


Taking the hash (SHA-1) of this concatenated message digests results in: 
H(hollAp) = 
= ee3e 9a3d ba2d da59 c663 1a58 Ice7c dd9e Ibec 3e99 (hexadecimal) 


Order message Payment message 
































order message: 31 5a 46 e5 12 83 f7 c6 47 payment message: 13 25 f4 75 68 
OM PM 
Vv Vv Vv Vv 
H SHA-1 H SHA-1 H SHA-1 H SHA-1 



























































(i) (Is 
h h 
Vv 9 P 
H 
Result Result H 
v C4511D95 4556f627 Vv 6E94DE9C AB3CB005 
FA491C85 ASA8CFOC H 35D792CA 05AAC971 




































































6AF4F62C 76A17D65 v 
13601344867 140015 19823723727533031546268859252377 h 13601344867 140015 1982372372753303 1546268859252377 
A A 
Vv 
D }e—kK,, E # kK, D \e—k,, 
A A 
DS 

















INTEGER: 
304401800 1682013330813613420039503951740 
0977022706040082090003630103 


HEX : EE3E8A2D BA29DA59 C6631 A58 1C7CDD9E 1BEC3E99 
INTEGER : 13601344867 1400151982372372753303 154626885925237, 


Figure 11.3. Computational analysis for the dual signature relating to Example 11.1. 
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Transforming this resulting hash into decimal numbers yields: 
H(ho||hp) = 136013448471400151982372372753303 1546268859285377 (decimal) 


The concatenated two hashes become the input to the SHA-1 hash function. Thus, the 
resulting hash code h is RSA-encrypted with the customer’s private key K,, = d, in order 
to obtain the dual signature. 

To generate the public and private keys, choose two random primes, p and gq, and 
compute the product n = pq. For a short example demonstration, choose p = 47 and q = 
73; then n = 3431 and ¢(n) = (p — Iq — 1) = 3312. If the merchant has the customer’s 
public key e, = Ky. = 79 that is taken from the customer’s certificate, then the customer’s 
private key d, is computed using the extended Euclidean algorithm such that: 


d, = e, ‘(mod o(n)) 
= 79 '(mod 3312) = 2767 


In the digital signature process, the roles of the public and private keys are reversed, 
where the private key is used to encrypt (sign) and the public key is used to decrypt for 
verification of the signature. 

To encrypt the final hash value h with d,, first divide h into numerical blocks h; and 
encrypt block after block such that: 


DS = A“ (modn) 


This is the dual-signature formula. Now, the dual signature represented in RSA-encrypted 
decimals can be computed as: 


DS= 3044 0180 0168 2013 3308 1361 3420 0395 0395 
1740 0977 0227 0604 0082 0900 0363 0103 


e Merchant’s signature verification: Since the merchant has the customer’s public key 
K,, = @¢ = 79, the merchant can decrypt the dual signature by making use of Ky, = é¢ 
as follows: 


Dx,.[DS] = h 
= 13601344847140015 1982372372753303 1546268859285377 (decimal) 
= ee3e 9a3d ba2d da59 c663 1a58 Ic7c dd9e Ibec 3e99 (hexadecimal) 


Now assume that the merchant is in possession of the order message (OM) and the 
message digest for the payment message h, = H(PM). Then the merchant can compute 
the following quantity: 


hm = H(H(OM)||Ap) 
= ee3e 9a3d ba2d da59 c663 1a58 Ic7c dd9e Ibec 3e99 (hexadecimal) 


Since hy = h is proved, the merchant has received OM and verified the signature. 
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e Bank’s signature verification: Similarly, if the bank is in possession of DS, PM, the 
message digest 4, for OM, and the customer’s public key Kj, then it can compute 
the following quantity: 


hg = H(A,||H(PM)) 
= ee3e 9a3d ba2d da59 c663 1a58 1ce7c dd9e Ibec 3e99 (hexadecimal) 


Since these two quantities are equal, hg = h, then the bank has verified the signature 
upon received PM. 

Thus, it is verified completely that the customer has linked the OM and PM and 
can prove the linkage. 


11.5 Authentication and Message Integrity 


When user A wishes to sign the plaintext information and send it in an encrypted message 
(ciphertext) to user B, the entire encryption process is as configured in Figure 11.4. The 
encryption/decryption processes for message integrity consist of the following steps. 


1. Encryption process: 

e User A sends the plaintext through a hash function to produce the message digest 
that is used later to test the message integrity. 

e A then encrypts the message digest with his or her private key to produce the 
digital signature. 

e Next, A generates a random symmetric key and uses it to encrypt the plaintext, 
A’s signature and a copy of A’s certificate, which contains A’s public key. To 
decrypt the plaintext later, user B will require a secure copy of this temporary 
symmetric key. 

e B’s certificate contains a copy of his or her public key. To ensure secure transmis- 
sion of the symmetric key, A encrypts it using B’s public key. The encrypted key, 
called the digital envelope, is sent to B along with the encrypted message itself. 

e A sends a message to B consisting of the DES-encrypted plaintext, signature and 
A’s public key, and the RSA-encrypted digital envelope. 


2. Decryption process: 

e B receives the encrypted message from A and decrypts the digital envelope with 
his or her private key to retrieve the symmetric key. 

e B uses the symmetric key to decrypt the encrypted message, consisting of the 
plaintext, A’s signature and A’s public key retrieved from A’s certificate. 

e B decrypts A’s digital signature with A’s public key that is acquired from A’s 
certificate. This recovers the original message digest of the plaintext. 

e B runs the plaintext through the same hash function used by A and produces a 
new message digest of the decrypted plaintext. 

e Finally, B compares his or her message digest to the one obtained from A’s digital 
signature. If they are exactly the same, B confirms that the message content has 
not been altered during transmission and that it was signed using A’s private key. 
If they are not the same, then the message either originated somewhere else or 
was altered after it was signed. In that case, B discards the message. 
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Figure 11.4 Encryption/Decryption overview for message integrity. 


SET FOR E-COMMERCE TRANSACTIONS 365 


Example 11.2 Message Integrity Check: 
User A 

Assume that the plaintext P is given as: 

P = 0x135af247c613e815 


The 160-bit message digest is computed from hashing the 512-bit padded plaintext by the 
use of SHA-1 as follows: 


h = 0x8d9af6616e6063£2900833c2dcafefdled08f459 


User A picks two random primes p = 487 and g = 229. Compute the product n = pq = 
111523 and @(n) = 110808. Suppose the A’s public key is e, = 53063 = Oxcf47. Then 
A’s private key da is computed using the extended euclidean algorithm as: 


da = ex'(mod $(n)) = 530637! (mod 110808) = 71 = 0x47 


A’s private key is used to sign (encrypt) the 160-bit message digest h to produce the 
digital signature Sa: 


Sa = 0x087760f9030ca3805ff4 19f4505e700cf3b 1 8becO00d0d0cce80c9ab 140dd057021a968 


Now, the message contents consist of the plaintext P, signature S, and A’s public key 
ea as follows: 


Message contents = 135af247c613e815087760f9030ca3805ff4 1 9f4505e700cf3b 1 8bec 
O00d0d0cce80c9ab 140dd05702 1a968cf47 

A generates a random symmetric key K: 

K = 0x13577ca2f8e63d79 

Using this symmetric key, A encrypts the concatenated message contents as: 

Encrypted message = 0x9adaff892d7c4db7f79 1 leacba780a6b 1c6444d77 1f289f5a 
12340aalccec658077f552 1 daddf1d78282aa96f4738426 


and then sends them to user B. 


User B 


User B chooses two random primes p = 313 and q = 307, which give n = 96091 and 
o(n) = 95 784, respectively. 

Assume that B’s public key, eg = 109 = Ox6d, is obtained from B’s certificate. The 
symmetric key K is encrypted with B’s public key to generate the digital envelope, which 
is computed as: 


DE = 0x009d100c5207c1313376156091606c 
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B’s private key dg is computed using the extended euclidean algorithm as: 
dg = 7745 = Oxle41 


The symmetric key K is recovered by decrypting the digital envelope with B’s private 
key dp. 


K = 0x13577ca2f8e63d79 


Using the recovered symmetric key, the encrypted message contents are decrypted to 
obtain the message contents (Plaintext + Signature + A’s public key). The message digest 
is computed by decrypting the recovered signature with A’s public key, and it results in: 


h = 0x8d9af6616e6063£2900833c2dcafefdl ed08f459 


Next, the message digest is obtained using the SHA-1 hash function of the recovered 
plaintext. It results in the following message digest: 


h = 0x8d9af6616e6063£2900833c2dcafefdl ed08f459 


Thus, the MIC is completely accomplished because these two message digests are iden- 
tical. Figure 11.5 gives full details of the MIC relating to this example. 


11.6 Payment Processing 


This section describes several transaction protocols needed to securely conduct payment 
processing by utilising the cryptographic concepts introduced in Sections 11.3—11.5. The 
best detailed overview of SET specification appears in Book I]: Business Description issued 
in May 1997 by MasterCard and Visa. The following descriptions of secure payment 
processing are largely based on this book of the SET specification. 

Figure 11.6 shows an overview of secure payment processing and it is worth looking 
at the outlines of several transaction protocols prior to reading the detailed discussion 
which follows. 


11.6.1 Cardholder Registration 


The cardholder must register with a CA before sending SET messages to the merchant. The 
cardholder needs a public/private-key pair for use with SET. The scenario of cardholder 
registration is described in the following. 


1. Registration request/response processes: 
The registration process can be started when the cardholder requests a copy of the 
CA certificate. When the CA receives the request, it transmits its certificate to the 
cardholder. The cardholder verifies the CA certificate by traversing the trust chain 
to the root key. The cardholder holds the CA certificate to use later during the 
registration process. 
e The cardholder sends the initiate request to the CA. 
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Figure 11.5 Message integrity check relating to Example 11.2. 
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Figure 11.6 Overall picture of payment processing. 


Acquirer 


e Once the initiate request is received from the cardholder, the CA generates the 
response and digitally signs it by generating a message digest of the response and 
encrypting it with the CA’s private key. 
The CA sends the initiate response along with the CA certificate to the cardholder. 
The cardholder receives the initiate response and verifies the CA certificate by 
traversing the trust chain to the root key. 
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e The cardholder verifies the CA certificate by decrypting it with the CA’s pub- 
lic key and comparing the result with a newly generated message digest of the 
initiate response. 


It is worth depicting this registration process as shown in Figure 11.7. 


2. Registration form process: 
e The cardholder generates the registration form request. 
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Figure 11.7 Registration request/response processes. 
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The cardholder encrypts the SET message with a random symmetric key (No. 1). 
The DES key, along with the cardholder’s account number, is then encrypted with 
the CA’s public key. 

The cardholder transmits the encrypted registration form request to the CA. 

The CA decrypts the symmetric DES key (No. 1) and cardholder’s account num- 
ber with the CA’s private key. The CA then decrypts the registration form request 
using the symmetric DES key (No. 1). 

The CA determines the appropriate registration form and digitally signs it by 
generating a message digest of the registration form and encrypting it with the 
CA’s private key. 

The CA sends the registration form and the CA certificate to the cardholder. 
The cardholder receives the registration form and verifies the CA certificate by 
traversing the trust chain to the root key. 

The cardholder verifies the CA’s signature by decrypting it with the CA’s pub- 
lic key and comparing the result with a newly generated message digest of the 
registration form. The cardholder then completes the registration form. 


The registration form process is depicted as shown Figure 11.8. 


3. 


Certificate request/response processes: 


The cardholder generates the certificate request, including the information entered 
into the registration form. 

The cardholder creates a message with request, the cardholder’s public key and 
a newly generated symmetric key (No. 2), and digitally signs it by generating a 
message digest of the cardholder’s private key. 

The cardholder encrypts the message with a randomly generated symmetric key 
(No. 3). This symmetric key, along with the cardholder’s account information, is 
then encrypted with the CA’s public key. 

The cardholder transmits the encrypted certificated request messages to the CA. 

The CA decrypts the No. 3 symmetric key and cardholder’s account information 
with the CA’s private key, and then decrypts the certificate request using this 
symmetric key. 

The CA verifies the cardholder’s signature by decrypting it with the cardholder’s 
public key and comparing the result with a newly generated message digest of 
the certificate requested. 

The CA verifies the certificate request using the cardholder’s account information 
and information from the registration form. 

Upon verification the CA creates the cardholder certificate, digitally signing it 
with the CA’s private key. 

The CA generates the certificate response and digitally signs it by generating a 
message digest of the response and encrypting it with the CA’s private key. 

The CA encrypts the certificate response with the No. 2 symmetric key from the 
cardholder request. 

The CA transmits the certificate response to the cardholder. 

The cardholder verifies the certificate by traversing the trust chain to the root key. 
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Figure 11.8 Registration form process. 


e The cardholder decrypts the response using the symmetric key (No. 2) saved from 
the cardholder request process. 

e The cardholder verifies the CA’s signature by decrypting it with the CA’s pub- 
lic key and comparing the result with a newly generated message digest of 


the response. 
e The cardholder stores the certificate and information from the response for future 


e-commerce use. 


11.6.2 Merchant Registration 


Merchants must register with a CA before they can receive SET payment instructions 
from cardholders. In order to send SET messages to the CA, the merchant must have a 
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copy of the CA’s public key which is provided in the CA certificate. The merchant also 
needs the registration form from the acquirer. The merchant must identify the acquirer 
to the CA. The merchant registration process consists of five steps as follows: (1) The 
merchant requests the registration form; (2) the CA processes this request and sends the 
registration form; (3) the merchant requests certificates after receiving the registration 
certificates; (4) the CA creates certificates; (5) the merchant receives certificates. 

The detailed steps for the merchant registration are described in what follows. 


1. Registration form process: 
The registration process starts when the merchant requests the appropriate registration 
form. 

e The merchant sends the initiate request of the registration form to the CA. To 
register, the merchant fills out the registration form with information such as the 
merchant’s name, address and ID. 

The CA receives the initiate request. 

The CA selects an appropriate registration form and digitally signs it by gener- 
ating a message digest of the registration form and encrypting it with the CA’s 
private key. 

The CA sends the registration form along with the CA certificate to the merchant. 
The merchant receives the registration form and verifies the CA certificate by 
traversing the trust chain to the root key. 

e The merchant verifies the CA’s signature by decrypting it with the CA’s public 
key and comparing the result with a newly computed message digest of the 
registration form. 

e The merchant creates two public/private-key pairs for use with SET: key encryp- 
tion and signature. 


Thus, the merchant completes the registration form. The merchant takes the regis- 
tration information (name, address and ID) and combines it with the public key in a 
registration message. The merchant digitally signs the registration message. Next the 
merchant’s software generates a random symmetric key. This random key is used to 
encrypt the message. The key is then encrypted into the digital envelope using the 
CA’s public key. Finally, the merchant transmits all of these components to the CA. 


2. Certificate request/create process: 
The merchant starts with the certificate request. When the CA receives the merchant’s 
request, it decrypts the digital envelope to obtain the symmetric encryption key, which it 
uses to decrypt the registration request. 
The merchant generates the certificate request. 
The merchant creates the message with request and both merchant public keys 
and digitally signs it by generating a message digest of the certificate request and 
encrypting it with the merchant’s private key. 

e The merchant encrypts the message with a random symmetric key (No. 1). This 
symmetric key, along with the merchant’s account data, is then encrypted with 
the CA’s public key. 

e The merchant transmits the encrypted certificate request message to the CA. 
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The CA decrypts the symmetric key (No. 1) and the merchant’s account data 
with the CA’s private key, and then decrypts the message using the symmetric 
key (No. 1). 

The CA verifies the merchant’s signature by decrypting it with the merchant’s 
public key and comparing the result with a newly computed message digest of 
the certificate request. 

The CA confirms the certificate request using the merchant information. 

Upon verification, the CA creates the merchant certificate digitally signing the 
certificate with the CA’s private key. 

The CA generates the certificate response and digitally signs it by generating a 
message digest of the response and encrypting it with the CA’s private key. 

The CA transmits the certificate response to the merchant. 

The merchant receives the certificate response from the CA. The merchant decrypts 
the digital envelope to obtain the symmetric key. This key is used to decrypt the 
registration response containing the certificates. 

The merchant verifies the certificates by traversing the trust chain to the root key. 
The merchant verifies the CA’s signature by decrypting it with the CA’s public 
key and comparing the result with a newly computed message digest of the 
certificate response. 

The merchant stores the certificates and information from the response for use in 
future e-commerce transactions. 


11.6.3 Purchase Request 


The purchase request exchange should take place after the cardholder has completed 
browsing, selecting and ordering. Before the end of this preliminary phase occurs, the 
merchant sends a completed order form to the cardholder (customer). In order to send SET 
messages to a merchant, the cardholder must have a copy of the certificates of the merchant 
and the payment gateway. The message from the cardholder indicates which payment card 
brand will be used for the transaction. The purchase request exchange consists of four 
messages: initiate request, initiate response, purchase request and purchase response. The 
detailed discussions that follow describe each step fully. 


1. Initiate request: 


The cardholder sends the initiate request to the merchant. 

The merchant receives the initiate request. 

The merchant generates the response and digitally signs it by generating a message 
digest of the response and encrypting it with the merchant’s private key. 

The merchant sends the response along with the merchant and payment gateway 
certificates to the cardholder. 


2. Initiate response: 


The cardholder receives the initiate response and verifies the certificates by travers- 
ing the trust chain to the root key. 

The cardholder verifies the merchant’s signature by decrypting it with the mer- 
chant’s public key and comparing the result with a newly computed message 
digest of the response. 
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The cardholder creates the order message (OM) using information from the shop- 
ping phase and payment message (PM). At this step the cardholder completes 
payment instructions. 


3. Purchase request: 


The cardholder generates a dual signature for the OM and PM by computing the 
message digests of both, concatenating the two digests, computing the message 
digest of the result and encrypting it using the cardholder’s private key. 

The cardholder generates a random symmetric key (No. 1) and uses it to encrypts 
the PM. The cardholder then encrypts his or her account number as well as the 
random symmetric key used to encrypt the PM in a digital envelope using the 
payment gateway’s key. 

The cardholder transmits the OM and the encrypted PM to the merchant. 

The merchant verifies the cardholder certificate by traversing the trust chain to 
the root key. 

The merchant verifies the cardholder’s dual signature on the OM by decrypting it 
with the cardholder’s public key and comparing the result with a newly computed 
message digest of the concatenation of the message digests of the OM and PM. 
The merchant processes the request, including forwarding the PM to the payment 
gateway for authorisation. 


4. Purchase response: 


The merchant creates the purchase response including the merchant signature 
certificate and digitally signs it by generating a message digest of the purchase 
response and encrypting it with the merchant’s private key. 

The merchant transmits the purchase response to the cardholder. 

If the transaction was authorised, the merchant fulfils the order to the cardholder. 
The cardholder verifies the merchant signature certificate by traversing the trust 
chain to the root key. 

The cardholder verifies the merchant’s digital signature by decrypting it with the 
merchant’s public key and comparing the result with a newly computed message 
digest of the purchase response. 

The cardholder stores the purchase response. 


11.6.4 Payment Authorisation 


During the processing of an order from a cardholder, the merchant authorises the trans- 
action. The authorisation request and the cardholder payment instructions are then trans- 
mitted to the payment gateway. 


1. Authorisation request: 


The merchant creates the authorisation request. 

The merchant digitally signs an authorisation request by generating a message 
digest of the authorisation request and encrypting it with the merchant’s pri- 
vate key. 

The merchant encrypts the authorisation request using a random symmetric key 
(No. 2), which in turn is encrypted with the payment gateway public key. 


SET FOR E-COMMERCE TRANSACTIONS 375 


The merchant transmits the encrypted authorisation request and the encrypted PM 
from the cardholder purchase request to the payment gateway. 

The gateway verifies the merchant certificate by traversing the trust chain to the 
root key. 

The payment gateway decrypts the digital envelope of the authorisation request 
to obtain the symmetric encryption key (No. 2) with the gateway private key. The 
gateway then decrypts the authorisation request using the symmetric key (No. 2). 
The gateway verifies the merchant’s digital signature by decrypting it with the 
merchant’s public key and comparing the result with a newly computed message 
digest of the authorisation request. 

The gateway verifies the cardholder’s certificate by traversing the trust chain to 
the root key. 

The gateway decrypts the symmetric key (No. 1) and the cardholder account 
information with the gateway private key. It uses the symmetric key to decrypt 
the PM. 

The gateway verifies the cardholder’s dual signature on the PM by decrypting it 
with the cardholder’s public key and comparing the result with a newly computed 
message digest of the concatenation of the message digest of the OM and the PM. 
The gateway ensures consistency between the merchant’s authorisation request 
and the cardholder’s PM. 

The gateway sends the authorisation request through a financial network to the 
cardholder’s financial institution (issuer). 


Authorisation response: 


The gateway creates the authorisation response message and digitally signs it by 
generating a message digest of the authorisation response and encrypting it with 
the gateway’s private key. 

The gateway encrypts the authorisation response with a new randomly generated 
symmetric key (No. 3). This key is then encrypted with the merchant’s public key. 
The gateway creates the capture token and digitally signs it by generating a mes- 
sage digest of the capture token and encrypting it with the gateway’s private key. 
The gateway encrypts the capture token with a new symmetric key (No. 4). This 
key and the cardholder account information are then encrypted with the gateway’s 
public key. 

The gateway transmits the encrypted authorisation response to the merchant. 
The merchant verifies the gateway certificate by traversing the trust chain to the 
root key. 

The merchant decrypts the symmetric key (No. 3) with the merchant’s pri- 
vate key and then decrypts the authorisation response using the symmetric key 
(No. 3). 

The merchant verifies the gateway’s digital signature by decrypting it with the 
gateway’s public key and comparing the result with a newly computed message 
digest of the authorisation response. 

The merchant stores the encrypted capture token and envelope for later cap- 
ture processing. 
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The merchant then completes processing of the purchase request and the card- 
holder’s order by shipping the goods or performing the services indicated in 
the order. 


11.6.5 Payment Capture 


After completing the processing of an order from a cardholder, the merchant will request 
payment. The merchant generates and signs a capture request, which includes the final 
amount of the transaction, the transaction identifier from the OM, and other information 
about the transaction. A merchant’s payment capture process will be described in detail 
in the following. 


1. Capture request: 


The merchant creates the capture request. 

The merchant embeds the merchant certificate in the capture request and digitally 
signs it by generating a message digest of the capture request and encrypting it 
with the merchant’s private key. 

The merchant encrypts the capture request with a randomly generated symmetric 
key (No. 5). This key is then encrypted with the payment gateway’s public key. 
The merchant transmits the encrypted capture request and encrypted capture token 
previously stored from the authorisation response to the payment gateway. 

The gateway verifies the merchant certificate by traversing the trust chain to the 
root key. 

The gateway decrypts the symmetric key (No. 5) with the gateway’s private key 
and then decrypts the capture request using the symmetric key (No. 5). 

The gateway verifies the merchant’s digital signature by decrypting it with the 
merchant’s public key and comparing the result with a newly computed message 
digest of the capture request. 

The gateway decrypts the symmetric key (No. 4) with the gateway’s private key 
and then decrypts the capture token using the symmetric key (No. 4). 

The gateway ensures consistency between the merchant’s capture request and the 
capture token. 

The gateway sends the capture request through a financial network to the card- 
holder’s issuer (financial institution). 


2. Capture response: 


The gateway creates the capture response message, including the gateway signa- 
ture certificate, and digitally signs it by generating a message digest of the capture 
response and encrypting it with the gateway’s private key. 

The gateway encrypts the capture response with a newly generated symmetric 
key (No. 6). This key is then encrypted with the merchant’s public key. 

The gateway transmits the encrypted capture response to the merchant. 

The merchant verifies the gateway certificate by traversing the trust chain to the 
root key. 

The merchant decrypts the symmetric key (No. 6) with the merchant’s private 
key and then decrypts the capture response using the symmetric key (No. 6). 
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Figure 11.9 Payment capture process. 


e The merchant verifies the gateway’s digital signature by decrypting it with the 
gateway’s public key and comparing the result with a newly generated message 


digest of the capture response. 


Figure 11.9 shows an overview of payment capture consisting of the merchant’s capture 
request and the gateway’s capture response. 
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